You can listen to the podcast and read the show notes here.
Michael: Welcome back to the podcast. I'm here with Nolan Erck from South of Shasta consulting. And we're going to be talking about ColdFusion best practices, but more importantly when the best practices are not the best practice. So we'll look at best practices and what they really are. What is technical debt, and why you don't want too much of it on your project. Picking two of good, cheap, and quick, and how to do that. We’ll look at a very naughty tag called C.F. form, and when they actually could be cool to use. And when it is okay to change code on your production server. We'll also look at some frameworks you may not be using, and what to do with error messages, and the best practice there. So, welcome Nolan.
Nolan: Thanks for having me.
Michael: Hey, I'm glad to have you back on the show. And Nolan’s being very popular. He was speaking in C.F. objective. I think you are in four sessions, or something.
Nolan: Part of four sessions, yeah.
Michael: Yeah, and he's also speaking N.C. Defcon, C.F. camp, and C.F. summit. So we'll talk more about those towards the end of the episode. But first, let's just clarify what exactly is a best practice? We hear about them all the time. What exactly is a best practice?
Nolan: So best practice is a technique, or a guideline of some kind that has generally been accepted by whatever community you're part of. In this case ColdFusion or CFML. As that's the at least currently less proper respected way to do whatever the task is you're talking about. The reason I say most current is sometimes, best practices of all over the course of the evolution of the language, or evolution of the technology stack, or whatever. So it might be a best practice today, may not have been a best practice five years ago. And it might not be a best practice five years in the future.
Michael: So you need to keep up with what they are.
Nolan: agreed
Michael: And a lot of companies have like a best practices document that they share with their team or what they think the best thing to do. But it's not white written in stone, you’ve got to revisited every now and again.
Nolan: Yeah, absolutely. One thing that I found I was actually discussing this with a few people in the ColdFusion community just a few days ago is there's also a difference in what best practices are discussed in the real world day job web development versus what your college instructors tell you is a best practice.
Michael: wow!
Nolan: So if you're learning a little bit of science at school right now. And I had this happen to me personally as well when I was working on my degree. The things that my C++ instructors would say this is how you build proper C++ apps. I was fortunate that I at the time worked at a place with C++ programmers, and I would then take the code samples from my professor to work, and show them that ask questions. And quite often, I'd have the day job employers say that's not how you actually do things in the real world. It’s slow, or there's a compiler bug that causes that not actually work the way your professor thinks it works, or whatever the thing was that we discussed. So sometimes, best practices are… Yeah, it's the current within the space you’re in adopted the correct way to do things for the time being.
Michael: So, what about technical debts, or what is that?
Nolan: So, technical debt is kind of related to best practices. And I guess the general consensus is the fewer best practices you use, the more likely you are to incur technical debt in your application. And technical debt is basically bad stuff that happens in your app. The example I usually give to my non-technical clients when I'm discussing changes we're going to make to their web that is we yes, we can do things, you we can fix your bug with this really short term quick fix. We'll take an hour or two, but there's a lot of technical debt involved in that. Or we can budget a little bit more time, and fix it a more proper way. They'll be less technical debt there.
And then I follow that up with technical debt that works like this: Say I have a great big dam hole in back water. The dam springs a leak. Well, the quickest way for me to fix that hole in the dam is just plug my finger in the hole. It took very little time, very few resources just to plug the hole, and we're done. And if a second leak springs up, I can do that again, and very quickly fix that problem. And that works short term very quickly to solve a small problem. But eventually, I run out of fingers. And if that eleventh leak happens, I can no longer solve problems that quick cheap way. I’m now stuck with a bug in my app, or a hole in the dam hole in back water that I cannot fix given my current set up.
The better practice in that case would be rather than stick my finger in the hole real quick and plug the leak, let's take the brick out that's damage, replace it with a better more structurally sound piece of brick wall and mortar, and whatever it takes to hold that section of the wall in place more properly. Yes, it takes a little bit more time, and resources up front. But longer term, that's the better way to go, and it makes the whole structure more sound moving forward. And that usually explain technical debt to clients. It's sort of like think of your code in your app as that wall that has sprung a leak. We can fix things quick and dirty now, but you might come back to resent that in a month or two. Or we can spend a little bit more time now fixing it the more proper way with better long term results.
Michael: Well, on the other thing that comes to me is if you've got too many places where you've stuck your finger in a hole, and you’re holding it there, it kind of reduces the maneuverability you have in the code.
Nolan: That's another great example. Yeah exactly if I have one hand holding back five hole… you know five leaks in one section of it I have. Yeah, I can only stretch so far to solve other problems, and in that structure. And yes, that's a great point as well.
Michael: And how this might show up is it might be you have you a database you know, isn't structured to well. Maybe it's not normalized, or is effectively a flat file.
Nolan: Yeah, there's all kinds of different ways you can incur technical debt in your application. It could be things like that the database level like that, not using foreign key constraints to keep your data integrity high, using yet not properly normalized data. It could be things as simple as the way you name a variable is if you're using like perhaps you’re using the word date for a variable in your ColdFusion file. And in ColdFusion, that it maybe it lets you use the word date. But when it that code gets translated into something that could store it in the database, maybe date becomes a reserved word inside your JBC driver. And then by the time it's the database it's causing sequel errors because there's a name collision with the reserved word in the database.
So things like well rather than naming… rather than using short easy to type potentially reserved words, maybe a better practice might be you want to combine a data type prefix on the front of your variable name. Instead of calling it date, if you're referring to the date someone was hired, maybe name is something like D.T. hired, or hired date, or something with takes a little bit more typing, but is a more long term better way to build things like that. And it could be small things like variable names all the way up to yet database integrity. It could be practices in place to not necessarily code you're writing about things like changing code on the production server. So this is a really quick fix. I don't need to go to the hassle of logging on my duff server, and make a change, and submitted a poll request and testing it on the Q.A. server first.
I know it's wrong. I'm just going to F.T.P. on to the production server now and make the change directly. And then, yeah that might be you know, that might take fewer minutes of time to fix. But now your code on production is out of sync with the code in your source control repository, and it's out of sync with what's on your development environment. So the change you make after that one, you're going to have ten times more work to do than previously had you just follow the practice of check code into your repository and use some sort of modern practice like Jenkins to push that file out to production correctly. You don't have any negative side effects of it.
Michael: Right because down the road, you might forget that you've done that and then you know maybe building a copy of the production server or.
Nolan: exactly
Michael: Get to copy that file over. Or another thing is maybe you didn't document how the server is configured, and now you having problems when you had to rebuild the server.
Nolan: Exactly yeah so. Sometimes, it feels like setting up best practices initially adds a lot of work to a project. And there can be a little bit of time you need to allocate when you start doing these things. If you're starting on a brand new project, or you're on a project that's been around for a few years, and nobody's used any good practices. There's no source control, there's no deployment system like Jenkins, there's not a proper Devon environment versus a production environment, things like that. Yes, it can take a little bit of time to set those things up initially. You may need to budget a day or two or something to configure everything and get it all dialed in.
But once it's there, everyone on the team moving forward has so much of a better, more efficient workflow. Everything just… it's so much better for everyone. I've got a client, we just set Jenkins up on their server. It’s kind of a newer client of mine. They had one server, no test environment, no Devon environment. Just a production server that the previous developer was writing his code on, and deploying everything out that way and I was working. When I when they became my client, they were asking us to make bigger changes to the site. Integrate different sort of payment systems, doing a little more Facebook integration, and some other kind of odds and ends that I just frankly wasn't comfortable just launching on to their production site instantly.
I figured not now let's set up a Q.A. staging server for you first, make sure the thing looks good there and it's proved correctly by you guys. You give it your blessing and say yes, it's ready to go, and then we'll push it live. So, the first thing we did was we set them up with version control. And all of their code is in GitHub which makes it really easy for my team to split the projects. Nobody's F.T.P.ing files back and forth, nobody's emailing zips of projects back and forth which is a giant pain in the neck. There are no DOT old or dot mind files in the code. It's all just dot C.F.M. and dot C.F.C. proper source code. And now, we also have Jenkins on their server as well. So, when I do fix something on my laptop, and I want to push it to the stage and server, all I have to do is check the code into the staging branch, and Jenkins takes care of the rest.
It sees oh, no one fixed a bug and he marked it as something they need to proof on the stage and server. It automatically copies that code down to the staging server and sends me an email on a slack notification saying that's ready to go. Go ahead and tell the client they can start proving that. They get their blessing, and then when I'm ready to push the change up to the production server, I do the exact same thing.
I take that change that was already written and just mark it as okay, put this in the master branch now. GitHub pushes it up to the server, Jenkins sees that new change, it copies it down to the production server for me, and I get an e-mail saying it's ready to go, and it's on the server. And none of us have to touch the servers, we don't have to log on and F.T.P. things back and forth. We don't have to log on and run any sort of scripts to copy old files over, or anything of that sort. It's all completely automated, it's repeatable, takes very little human interaction it just makes everything overall better when you use good Study best practices like that to work on projects.
Michael: Great! So, we talked about before we go on the episode about good, cheap, and quick pick too. Tell us a bit about it that.
Nolan: I don't know where that phrase initially came from. But I've heard it used in software development conversations for a long time now. The idea is you can build something. Any two of those ways that you want, but you'll never get the third. No matter how hard you try out of your application. I can build something cheap, and good, and cheap, but I won't get it… It won't be quick. I can build something good and quick, but it won't be cheap. Whatever the third thing is that you're trying to get around, whatever way it is you're trying to get all three of those, you never actually get all three of those when you're building an application.
There's just not a way to do that. If I had developers that work really, really fast, and they're very, very good at what they do, well I'm paying for those resources. There's not a person in the world anywhere that is an amazing developer, and writes things just lickety split, super-fast, and only charges ten dollars an hour; that just doesn't happen. If you want very, very good resources, you have to pay for them in the payment time, or in the number of people you have, or the quality of people. There's some sort of a trade off in whatever it is you're trying to do.
Michael: Or you might be paying in technical debt.
Nolan: Exactly, that’s the other thing. You might be paying in human dollars for buying the time of different smart people to work on your app. Or you might be buying it in terms of technical debt, yeah. That's another example that I've heard used about technical debt a lot too. Is it sort of like taking a loan out at a bank. If I need money right now to start my business, well, the quick way to do that is get a loan from the bank.
That's quick but it's not necessarily cheap, is it? They’re going to charge me interest on that loan and eventually, that loan has to be paid back with all of that extra interest on top of it making it a bigger, more involved project than it was initially. And technical debt is kind of the same way. Yes, I can do a real quick fix on your app, and take out a loan against the code right now, solve all these problems. But eventually, that loan with the interest gets paid back. And that's the technical that we have to deal with.
Michael: And if you get too much technical debt, the code can totally collapse.
Nolan: It can yeah. There are times I've seen applications that were just not managed well by anyone with proper architecture vision about things. And there's just so much legacy code in the app that you can hit a critical mass point where clients will call up with what should be a seemingly easy request to change in the code. And yeah, the more technical debt there is, the more likely… and this has happened.
Sometimes, I have to call the client back and say, “You know what? That should be an hour worth of work but because of problems X, Y, and Z that your previous team never addressed, it's now going to take me three days to undo all of that stuff, and do it properly in a way that won't open up a bunch of security holes, or break ten other things, or whatever. So yeah, it very much is a balancing act. You have to be mindful when you're building software.
Michael: So, let's have a talk about some of these different things that are regarded as best practices but aren’t always best practices. And the first one is that attack that people can’t really avoid like the plague which is C.F. form.
Nolan: right C.F. form
Michael: So, why is that a best practice to not use C.F. form, and then why did you choose to use it on and on a particular program?
Nolan: So, C.F. form, and all of the related what they call ColdFusion U.I. tags. S, C.F. select, C.F. grid, C.F. input. All of those kind of tags in that family of features in ColdFusion. They're all kind of considered a bad idea for the same reason. That reason being those tags, they generate U.I. code when you use them. So, if I used to C.F. form and C.F. selected tags, what those tags actually do is they render out H.T.M.L. and JavaScript to the client side as part of their… the result of using those tags. Lots of other tags we have in apps generate H.T.M.L. output. I've written a bunch of custom tags myself to do that. That in itself is not a problem. Here's the problem with that.
The JavaScript libraries used by those C.F. form tags internally, are not things you can update manually. So like I believe they use E.X.T. J.S. as one of the built in JavaScript libraries in the ColdFusion U.I. tags. Let's say E.X.T.J.S. library comes out with a new version of it. Version Seven is out of that library, or that library completely gets deprecated and the people in charge of it say, “You know what? Never mind stop using that. We're not supporting it anymore. If you find security holes in that code, or bugs we're not going to fix them, just stop.” There's no way to drill into the ColdFusion engine and easily remove those files and update them with a new version of whatever that JavaScript library is. So by using the built in ColdFusion U.I. tabs, you're locking yourself into what is pretty quickly dated JavaScript libraries in your app.
And JavaScript moves so quickly these days. You want to be able to get in there and swap out whatever JavaScript libraries you're using, and put in the new ones with the better bug fixes with the newer features pretty quickly. And there's just no way to do that with the ColdFusion U.I. tags that are baked in there. And plus the quality of the output from those tags just isn't that great to be perfectly honest. I love ColdFusion. I think the product itself is really good. They tried to make those tags be sort of a one-stop shop solution for lots of different use cases.
And that's really, really hard to do and the just these techs kind of fell short of being able to do that. So, a lot of people find that when they start to use those tags, they work okay for small to medium sized web pages. And when you get beyond that, and need a little bit more fancy or complicated functionality, those techs fall short really quickly, and then people that have used those tags all over their app, they’re kind of locked into using those tags. So in addition to using these bad U.I. tags, they're now having a stack a bunch of H.T.M.L. and C.S.S. hacks on top of it to get the output that they want in their app. And just it's kind of a bad way to go about doing it.
The better practice these days is don't use those tags, just write plain H.T.M.L.5 tags, and use… You can use JavaScript libraries. There's nothing terribly wrong with using your jQuery or jQuery, or jQuery UI, or whatever the thing is you're using to make your output look how you want to look. The ideas just don't use the baked in libraries that come with ColdFusion. Import your own. Just go out to jquery.com, or whatever the library is you want. Download the files yourself, and then just add the script tags to your site header, or site footer to import those libraries. Import those libraries yourself and that way, when a bug fix comes out, you can add the bug fix easily to your app without being locked in anything from the ColdFusion engine.
Michael: Well, that all that makes good sense. But you found a project where it made… it did make sense to use CF form.
Nolan: I did yeah, so the… Historically, the best thing about ColdFusion when it first came out for a long time was it's super easy to start using ColdFusion. You don't have to actually be a senior advanced web developer to start writing CFML pages. And that's been one of the big selling points for a long, long time with that app. So, as part of my consulting business, I teach classes on how to build different sorts of web, and mobile projects. I'll teach three day boot camps on building Android apps or writing database queries whatever the thing is. And I got books to teach a… I think it was a three or four day class on ColdFusion. So I showed up and there were three gentlemen in the class. They said okay, here's the situation none of us are developers. I said okay, that's fine, don't really need to be hard core developers.
They're going no, no, no. I'm in marketing that's a database server maintainer guy. And the third over there has a little bit of a marketing background too. They all work for the same company. There was a horrible restructuring at their office recently, and a lot of the I.T. guys lost their jobs. So for some reason, the powers that be pointed at these three guys who are not technical and said, “You three are now in charge of running the company internet. Go figure out how to learn ColdFusion. Your jobs depend on it.” So they showed up at my class, and said, “Help me to figure this out.” So, we spent about a day trying to do kind of basic programming concepts. Here's a variable, here's an F statement, here's a four loop.
A little bit so that made some sense, but I could tell by just how they were reacting in the class that the light bulbs weren't actually clicking on for these people. They were kind of watching what I was doing and saying, “Okay, I guess that yeah, if I make a variable called X. and I stick twelve in that, and then I do C.F. output X, okay, it's going to show up on the screen.” But they're having a really hard time grasping, how do I write a bunch of code, and use this in the application at work? And how do we connect all these things together so that I have a job tomorrow? So we talked about what their Internet did. And it turned out their Internet it was all older ColdFusion stuff, very much tag based C.FML. Most of which was just list pages of output from a database table and then a detail page. When you click on a link and that shows you that each old record of that.
I think two of the three gentlemen had used Dreamweaver a little bit before to edit basic HTML pages. So, they were kind of familiar with Dreamweaver. And I thought okay well, Dreamweaver has ColdFusion support baked into it. Let's turn on the ColdFusion support. And now, instead of writing code, you're literally just dragging and dropping things from the right hand column into the pages on your website in Dreamweaver. And you can edit things in little display panels in Dreamweaver rather than purely writing code. Yes, it's writing code behind the scenes, but they were much more comfortable in a visual layout environment like that. I thought okay well, we can do that. The downside to doing that though is all of the ColdFusion stuff that's baked into Dreamweaver is the C.F. tag. C.F. form, C.F. select input.
Those sorts of table those sorts of things are what you drag and drop in the Dreamweaver panel to build ColdFusion pages in inside Dreamweaver. So I went all right, well let's see if this makes any more sense. Turn on Dreamweaver and then you can just click on things and say okay, here's where you put your database query. They had a database guy that can write queries, so that part was easy enough to do. You can click in here and say okay look, all your columns show up in this little panel. Just drag and drop of the things you want on the panel and hit save or render whatever the buttons at the time. And that seem to make a little bit more sense and got them further along the path.
So, rather than grinding away for three or four days trying to teach three very non-technical people how to become technical – which was proving to not be a great use of anyone's time; we went with let's use draw right. Here's Dreamweaver. Everyone have a copy of Dreamweaver? It's 200 bucks. Just grab this from you know, fill out a real quick response for your office, put this on your three computers, here's how you do this. And then show them like look you can drag and drop a query, you can add a link to your detail page. Just going to do this for all the pages in your Internet, and you should be all set.
So yes, I told three or four people use C.F. form, use C.F. select, build your apps that way because that was the right solution for their predicament. It was that or it was send them all back to work the next day having no idea of what to do with a mountain of homework, and they didn't need a lot of homework. They needed to make sure they knew how to build these lists in detail pages on the company internet, and tell the boss yes, we can do this for you so. Yeah, I told them. I didn't tell them these are bad idea. I just said here's click this little thing. Click to see a select and click the C.F. table, and that's how you get the results you want. Okay, and they were off to the races.
Michael: So let's go to another best practice why you broke it. Which the best practice would be don't and it code on the productions of it directly.
Nolan: Right that we mentioned earlier when we talked about the client that didn't have source control, or Jenkins, or anything installed. Yes, it's a horrible idea to edit code on your precious server. I would never recommend even fixing a typo that way I would always push. Even if you add in a comma to a sentence, I would push that through version control the proper practices just make sure everything stays in sync. I had a client I worked for a couple of years ago, kind of a smaller outfit about five people at the company. And my main point of contact was the V.P. of I think marketing basically. He knew a little bit about H.T.M.L. He was decent with his H.T.M.L. He knew what he knew and he knew not to go any further than that.
So he could make a new paragraph of content on the page, he knew how to create a link make certain words bold, and italic; and that sort of thing. And he was good at doing that bit of work. He did not want to spend the time setting up the dev environment on his laptop. He didn't want to waste time with the staging Q a server. He wanted to find a typo on the website, or find a place where he needed to add a new paragraph of text and be able to change it, so he would. And he was at least good about he understood his code has to be in sync with my code. So, he would make changes, and then email me and say, “I change these three files please update your environment to match.” And after a while, we would do that, and we kind of went back and forth over well. I should be making all of the changes.
He's like no, I'm going to keep making changes, don't slow me down. You're already working on writing code on the backend. I'm going to keep doing this thing here and I explained to him like we don't want to get out of sync. We've already accidently overwritten your code once or twice, let's prevent that. And he does… He's like I'm the V.P. of the company. I don't have time to do this dev staging Jenkins contingent ration stuff. It's my laptop, I have Dreamweaver installed, and an F.T.P. client, I know how to use it. Nolan, find a way to let me be productive doing what I'm doing, and solve that problem. So I thought okay, he's not going to follow the typical practices of a developer. He's going to make a change on his code F.T.P. it up to production, and be done, and that's all he's going to ever do.
So, I keep trying a few ideas, talk to him a little bit more. And we did agree that… We came away for had a… I asked him one day, well when you're done making changes where you at least click a link that I send you to let me know you're done making changes. And he said yes, I'll click a link when I'm done making changes so that if that sends you a notification of some sort, you can do that. It's great! So, I made a URL on the website for a C.F.M. file. And you can do this with any language, it's not ColdFusion specific. We installed Get on his production server. And what happens is whenever he clicked that, ‘I'm done making changes link’. That link would do a Get commit on the production server of any code he changed, it would make a new branch or just do a commit or something. Or it would mark all the changes he did and sic them into the good repo for me.
Then he would email me and say he may changes to these files, make sure you grab the latest things down. So, he wasn't using Get as far as he was concerned and he didn't have to change his workflow other than clicking this link once a week, or so whenever he made changes. But all the code got in to Get, and got mark and source control properly. And we were able to keep everything in sync, and keep it all safe. My biggest worry was he would change something maybe accidentally delete a line of ColdFusion code not realize he'd done that, and then blame me. And he would call my phone and say… and he had done similar things a couple of times before kind of just innocently not trying to be a jerk client, or anything.
He just little bits of code to change he didn't realize they changed at all and what if you break. Well, if I'm making some of the changes in source control, and he's not following source control practices, I don't have a good neutral third party report to reference saying, “No, actually, you are the one who changed a lot of code. It wasn't me or my team.” But by getting him to use this ‘save my changes link’ that I gave him, his workflow stayed basically the same, but everything got marked into source control.
Even though he was breaking a best practice by changing code on production. Technically, yeah it was still on marked code that was not in GitHub for the few minutes it took him to open that link and click it. But it was still a heck of a lot better than just letting him blindly change things on the FTP server, on production through F.T.P., and then emailing me whenever he was updating files just. So yeah so, till this day, I think he still clicks that link whenever he’s making changes and it automatically adds things to GitHub for him and checks into the repo.
Michael: cool
Nolan: But it's working.
Michael: alright
Nolan: Not a great practice but…
Michael: But it works for him. It was the right thing for him.
Nolan: Yeah, it was the right thing for him. I wouldn't recommend it for the whole world though.
Michael: No, so let's talk about framework. So, what's the best practice on frameworks? Should people be using them or?
Nolan: Yes, so just for clarity, we're talking about N.B.C. frameworks because there are Dependency Injection frameworks, and other things out there. But overall, yeah. If anyone's building anything bigger than a glorified brochure website. Like if you have a website for a hair salon. You probably don't need much more than a page showing the hours you're open, maybe a page with a few photos showing different hairstyles you do, and a page with prices or names of the staff; something that small. You probably don't need a framework to do, to handle that. Anything kind of medium sized and up. Yeah, you need some sort of N.B.C. framework to manage the application.
And I pretty much always just by defacto any time I’m building a website, I grab either framework one or ColdBox and use that as the… I don't even think about it anymore. I just start with one of the frameworks based on what I'm doing, who the client is what kind of features I might need and go from there build my apps. And one of my early clients had a very large web site that you could argue could be done with an N.P.C. framework. We weren't building anything that couldn't be done that way. The problem we ran into more so it was the team itself in the knowledge base of everyone that needed to be productive on the team. It was myself as the project lead, and the C.T.O. of the company who was designing the software. He knew all of the business rules. This was an app for the semiconductor industry.
So, we were building software for companies that make and sell microchips. And of the C.T.O. knew all of the business rules of how that needed to work. He was designing the data model of what the database should look like, and how the business rules for required fields and that sort of thing function. But he's not a web developer. His background was FORTRAN, and assembly language on pretty old processors. Nothing I can really use in a web development world. But he needed to be productive, and be able to describe the business rules on a page by page basis. I don't know how much you, or the listeners of the podcast know about building microchips, but it's not like ordering T. shirts. You don't just say I want 400 large blue. There are thousands of parameters that go into ordering and designing a microchip.
So, he needed to be very productive very regularly so he could go in and change the requirements of these fields are required. Except if A, and B, and C are true, then D is not required, or whatever the things are he was describing. I also had two junior developers working with me one of which knew some ColdFusion. She had passed the ColdFusion certification test before. The other one was a guy who knew some P.H.P. and was trying to figure out ColdFusion to help me out. And that was the team that we just had available at the time due to circumstances. So, I needed all these people with different backgrounds to be very productive very quickly.
We had several demos with clients at conferences, and trade shows that had already been booked. So we needed to make sure are right, how do we get code working quickly to at least show off the greatest number of features in the app? None of the clients that are going to see this demo are going to look at the source code. None of them are going to be able to tell if we used ColdBox, or not let alone be able to judge the type of technology we're using under the hood. They just want to see the business rules in place and say, “Yeah, that's what we need to use to make microchips. This is great, let us buy one.”
So I have a P.H.P. guy, a junior ColdFusion person, a FORTRAN based C.T.O., and myself. How do I make them all productive very quickly? Well, it turned out everyone either knew, or could understand X.M.L. very, very fast. X.M.L. made a lot of sense. So we just sort of wrote our own domain X.M.L. based language rather than spending a lot of time teaching people the ins and outs of database queries and C.F. this, and C.F. that, and this tag, or that tag, we just started describing the different pages in the app of which there were a lot using this X.M.L dialect instead. Okay, here's how you… Ye need to reference this layer in the microchip just use a layer tag and then you put these things on there, and that will mark these parts of the layer as required.
You need to reference this part of the geometry and the microchip, just use the geometry tag and do it this way and that would describe the next piece of the app. And then underneath the hood, I just had a ColdFusion engine that I was more responsible for that could look at that X.M.L., and then turn it into usable required fields. When things get stuck in the database, I can know which things are required, which ones aren't. I can enforce business rules that way. So, my options were used the sort of X.M.L. based thing that everyone kind of understood quickly, and was able to be productive with. Or spend a lot of time teaching three very different people and M.V.C. and object oriented programming which I recommend doing.
Those are the best practices in not just ColdFusion land, but most modern web development. The reality is we live with a lot of these decisions because of the constraints from the conferences, and trade shows that had already been booked because we had deadlines that had to get. There were great big trade shows were huge companies were going to be watching this product. And I wasn't going to be in the room, nor was I… nor was it right for me to explain, “Well, we're trying to teach our junior developer what an object is right now. And as soon as he learns that then, we'll be able to build this for you.”
I just had to say no, here's tags, here's the X.M.L. things I wrote. Put this in your files, it'll generate the right output and go from there. So in that case, yeah, we skipped model glue, we skipped ColdBox, we skipped framework one. We looked at a couple of different M.V.C. frameworks early on. And my gut just told me like you know, this is going to save us any time right now. It's going to make things a little bit more slow for everyone involved in this project. I'm just going to skip it and go with the custom solution instead, so we did.
Michael: Cool! So, let's talk about error handling, and the best practice for dealing with errors which I'm going to guess is logging, or why you wouldn't necessarily do that.
Nolan: Yeah, so a lot of people recommend if your app throws errors, use the C.F. log tag, or some sort of logging mechanism to log all of those errors into a log file, or a database, or something of that effect so that you can have an I.T. person look at that log. And look at the reporting based off of that later, and tell what types of errors are happening, and how frequently they're happening in your application. Separate from that, it is very easy to set up code in ColdFusion and other languages too. So that any time your app throws an error, it sends you an email instead. Here's a copy of the error that I received, here's a copy of all the form variables and all the user variables that were in play at that time. Maybe a copy of the user session scope, whatever other odds and ends you have available, and do that, and that technically works.
But if your application throws 200 errors a day, you get 200 emails you have to deal with. And they can all look very, very similar. If it was not 200 different people, it was one person just clicking the same button over and over again, you might have 50 emails from the same frustrated user. There are no metrics and you just get emails dumped to you that way. So, it's hard to tell is this 50 different errors from 50 different users? Or is it one person that just got frustrated, and kept clicking the button over and over again? And that sort of thing. See a lot of people frown on shooting emails to your IT staff or to anyone when an app throws an error. They say, “No, put it in a log is a tool like bug log H.Q. to track all those errors and monitor them and just go from there. And normally, I recommend that too that is the better way to go for most situations.
I had a client that had a legacy ColdFusion application. The previous developers were no longer around. They asked me to come in, and sort of babysit the application, and see what I could figure out about it. And the office where this particular client is all very, very nice people none of which are technical. They wanted to know what their server was doing though. So, I could have spent the time installing bug log H.Q. and setting up metrics and using fairly technical terms to explain to them things like, “Oh well, this problem happens because your form post variable buffer is not big enough. This problem happens because the sequel had a G B C error and blah, blah, blah, blah, blah; stuff that none of them care about. But that particular office, they do so much work by e-mail, that just the culture there is they email everything.
They don’t use slack, they don't use text message.
They just shoot emails back and forth to their staff all day long, that's how they like to work. If they see four messages coming from the V.P., they he's excited about something or doing something. A lot of work on a particular topic. They see multiple emails coming from an account manager that's working on event X. Y. Z., they know that something's happening with that event. And I just… that's how they like to work. So, I proposed to them Okay well, how about anytime your site throws an error, I'll have it shoot you an email with all the details in it. You probably won't be able to understand the details; that's fine. But you'll be able to at least tell about the volume of emails you get, is the site working properly today or did something happen? No emails me that's fine and if you get 50 emails, give me a call and I'll see what I can step in and take care of.
And they love that idea. Yeah, yeah let's do that! And nobody on the team has been… They haven't added any technical people to their office. There's no one there that understands those emails now more today than they did when I first set this up for them a while ago. But they like that ability to just tell, oh, the site seems to be behaving today. We saw two emails come through for errors and nothing else happened. And then they can tell when something is going wrong because they'll see the flood of messages coming on their server. And for that particular client, they liked that visibility it just the sheer fact that they got an e-mail. What they understood the technical pieces of it or not, that was enough transparency to them to that where they can tell what the server is or isn't doing.
They can tell when we push the change up to the server, did it work well? They got no emails. Did something bad happen from that change? Oh, they got a whole bunch of error message e-mails that day. They can tell… they get that kind of visual indicator to them that works well for keeping track of how their applications are behaving so.
Michael: cool
Nolan: And it’s like that. I have… I still suggest this to clients every once in a while. I get a client that has kind of a similar mindset, they do a lot of stuff over e-mail, they love their iPhone, they always look at messages not super technical. It's probably not worth my time to try to explain to them how I.I.S. does writing in and out of the ColdFusion engine or how Form variables are processed, or whatever the thing is they’re discussing.
But I’ll sometimes tell them, how about this? If your site throws an error, I'll have it shoot you an email. And if you get a lot of emails with a lot of errors, something's going wrong. Give me a call. Okay, yeah that sounds great. So, not the recommended practice, not something that a lot of the speakers at conferences like to promote. I don't think. But… Or the occasional client seems to be the solution that they enjoy the best. Enjoy is probably not the best word, but you know what I mean they…
Michel: It works for them.
Nolan: Yeah, it seems to work for them.
Michael: So, what about when the problem isn't code and you are the developer and you're kind of stuck in the middle.
Nolan: Yeah, that kind of thing happens sometimes too. You do have cases where the technical debt isn't really lines of code that are bad. The technical debt is more of a process issue. Things like maybe you’re… I've had this happen before. I've seen it happen. People in the network operations team, where the I.T. team would be there rightfully so very paranoid about people trying to break into the website and cause problems. That in itself is not a bad thing.
What I ran into though was one I.T. department that said, “We are not allowing any URL’s in our application nor any form variables in our application to include the word alter; ALTER. Because that could be somebody trying to alter something in the database. You need to go through all of the code, and everything in the app, and change anywhere where it says alter; ALTER to be ALTR, so we can tell the difference in a hack attempt versus you're doing whatever legit thing you're doing in the database where you need to use the word alter.
First of all, it's a terrible waste of everyone's time, and resources, and money. Second, that's at best a very outdated mindset about how you build, and secure web applications. And third, what do you do if somebody is trying to sign up for an account in your app and his name happens to be Walter; W A L T E R? That guy is now going to get an error just typing in his first name. It should never happen in an application regardless of what kind of security you're trying to implement. The problem there isn't code, it's nothing in the database. The problem there is education. The people in charge of that server are just out of date, or just not properly communicating what they're trying to do with the rest of the team. So, what we recommend in those kind of cases is find somebody else that is a high stakeholder in that project.
In my case, I had a lot of success with the vice president of marketing. The marketing team tends to care a great deal about what the website looks like, and how users interact with it successfully. They don't care as much about how many lines of code it took to write it. They don't care what they are using ColdFusion, or FORTRAN, or whatever else. They just want the website to look and behave the way they expect it to by the deadline. So in those cases, I had a lot of success. I would just contact the V.P. of Marketing and say, “Here's the situation, here's the problem, here's what the net team, the network operations team is recommending we do. And here are the problems I see with that happening.”
And as soon as I turn it into things that the marketing team cares about like your users will have a work lesser experience if their name happens to be Walter. They will not be able to sign up for accounts. They will not be able to click on links to generate revenue for the company. As soon as I start using marketing terms and concerns like that, they're very quick to get on board with solving the problem a different way.
And they'll back me up on talking to the network operations team and saying, “Yeah we can't do this ALTR versus alter thing, that's just not going to happen. Find another way to solve the problem.” And the reality is that should never be a thing anyway in the case of ColdFusion just use C.F. query program and that will solve the bulk of your sequel injection concerns about that sort of thing. So, they're quick ways to do that that the net ops team just didn't happen to be versed in at the time. Yes, sometimes, a problem isn't code. Sometimes, it's a need to educate the developers, or other people just involved in the project technical, or otherwise and go from there.
Michael: Great! Well least being great best practices and you know realize they're not set in stone sometimes you need to do things differently.
Nolan: yeah absolutely
Michael: So, let's shift gears a bit now. A question I’ve been asking a lot of people on the show is, why you're proud to use ColdFusion?
Nolan: I'm proud to use ColdFusion. First, I'm a consultant for a living. I've been doing this for about ten years. I've made all of my money in that time (not to sound arrogant). But I made all of my money by having a good reputation for what I do. I don't advertise on Craigslist, and things like that. People like the job I do and they pass my name on to someone else, and I get more projects that way. So often, clients will call me and they'll say, “Here's the problem we're trying to solve. Whether it's the app want to build, the website we want to build; whatever the thing is. What do you recommend as the best solution for that that problem?” So, I try to look at everything objectively. And so okay, what truly is the best technology stack to use for this problem?
And nine times out of ten, it's just ColdFusion every time. I'm quicker with it, you get more done per line of code out of the box. Yes, you can do a lot of the similar tasks with dot net and P.H.P. and whatever else. But you often have to buy out on packs of some sort to get those to work or you're writing more code. You're importing more third party libraries; things like that to get the same kind of results I get for just a fresh install of ColdFusion. So, I just… I get more done with it straight out of the box. It makes my life easier, it makes the projects go more quickly. A lot of that integration from different third party libraries has already been done and Q.A. by Adobe. I have fewer headaches to worry about when building larger scale apps. It just works, and I really like that about it.
Michael: Cool! So sometimes, people have said ColdFusion is dying. What would it take to make ColdFusion more alive this year?
Nolan: I think my personal take on it is yes, the number of people using ColdFusion is getting a little bit smaller, but I think it's… I think we're now seeing sort of two camps of people in ColdFusion. There's the very advanced kind of modern web development camp. People like the order solutions team. They're doing a lot of really great modern innovative stuff with ColdFusion, and that team is going really strong. We're also seeing a lot of people on the other end of the spectrum who are what I call the legacy ColdFusion developers. People who learned how to use ColdFusion in maybe 2000, or 2001. They learnt how to use the C.F. include tag and maybe custom tags, and they kind of stopped learning at that point. They're not doing object oriented development, they're not following best practices, they're not using N.B.C. frameworks.
Those two camps seem to still be kind of steadily maintaining, or maybe growing a bit. It's that middle group that learned more than just the five tag C.F. include stuff. But not enough to truly be a really forward thinking, object oriented modern web development group. And that middle group that's been kind of going down I think. It's just my opinion. That groups been getting smaller in the last few years, those are the folks that are moving on to other technology, those are the people who have been the most vocal about ColdFusion is dead. And so, now, they're jumping ship and using Ruby, or Python, or whatever the thing is that interested them the most.
I think the thing that's going to help keep ColdFusion alive the most is that forward thinking group. People like the orders team, and the blue are team with [inaudible] [45:40] C.M.S., the framework one guys. All of those guys that are doing the forward thinking work that's building modern tooling for ColdFusion. We need more of that, and we need people that are in sort of those camps to help with educating the people on the other side. So, you get a lot of… There's a lot of web development still being done in ColdFusion where they're just using the old technology; C.F. include and custom tags and not a whole heck of a lot else. Either because they're scared to learn the new things, they think it's going to be overly complicated. Maybe they think it's too many files, or too much code.
It doesn’t actually solve the problem I solve. Maybe they're just not aware of it either. There are a lot of people that just for whatever reason are not able to budget time and money to go to conferences and to learn what the current trends are. And I think we need to bridge that gap more and fix that problem. Let's take the people that are still writing code as if it's 2001 whether intentionally, or otherwise and help them fix that problems. Like you know what? It's actually not that hard to go from your C.F. include stuff that you're comfortable with into a small N.P.C. framework like framework one. And then, if framework one doesn't solve every problem that you have, well, it's pretty easy to add on things like test box or D.I.Y. one, or wire box, or whatever afterward when you get to the point where that would help solve a problem for you.
On that note, I actually shameless side plug. I give a presentation sometimes at conferences called M.D.C. with and without a framework that is exactly for that people in that predicament. People that are still writing C.F. include based code. They don't really quite know how a framework one, or ColdBox works and they need to kind of be [inaudible] [47:17] along those steps to gradually get up to okay, N.B.C. isn't quite so scary. I can actually do that. It's not as weird as I thought it was. So if people want to check out my website, they can download the slide deck and code samples from that talk, and hopefully, learn a few things about how to improve their skill set there. But [crosstalk] [47:24] training and helping to educate the community.
Michael: Cool! We’ll put links to those in the show notes for this episode. And I also think one of the ways. You know if people can’t afford to go to conferences, listen to the podcast episodes or…
Nolan: yeah
Michael: … read some blog articles.
Nolan: Yeah, absolutely, the podcasts are great. There's this C.F.M.L. slack channel. If people want to hang out on slack and chat about ColdFusion, they can do that. I blog myself when I can. There are still several people that blog about ColdFusion. [Inaudible] [48:05] Dell of course has his blog up still. [Inaudible] I believe has all of his ColdFusion content still online. There are a few people floating around out there the blog things. The mirror guys. I don't know if it's mirroredgetmirror.com or if it's blueover.com. But one of their websites has a blog on it now too where they're posting about at least different things you can do with mirror C.M.S. and that's of course all ColdFusion based as well.
Michael: So, you're going to be speaking at a bunch of conferences. You're going to be at N.C. Defcon C.F. camp and C.F. summit. So, tell us what you're looking forward to at these different conferences.
Nolan: Let me see. They're all really good conferences for different reasons. N.C. Defcon, I really think that's an underrated conference. N.C. Defcon is… First of all, it's a weekend. So, nobody has to take a lot of time off work to actually go to the conference, and that's a big pain point for a lot of people. They say, “Oh well, going to my boss won't pay for vacation time for that. So if I go, I have to use three or four days of P.T.O. to attend a conference. I was going to save that P.T.O. for the family vacation next year, or whatever. N.C. Defcon is Saturday and Sunday, so there's no time off work. Tickets are really cheap for that too. Don't totally quote me on this, but they're around the 200 maybe 250 dollar range for the whole weekend. You get three, four, maybe five tracks with of content.
There's ColdFusion stuff, JavaScript, modern tooling and security, and all kinds of things, and it's a weekend in North Carolina. So, the weather's usually really good, everyone's friendly there. It's a really great, great setup. People that run that conference do a great job of organizing everything at N.C. Defcon. I recommend that to everyone I know that has even a remote chance of going. I live in California. It's about a five or six hour flight for me to get to N.C. Defcon, and I still go every year. Worst case scenario, I have to leave work a couple hours early on a Friday.
Maybe cut out at noon, fly out there, go to the conference all day Saturday, all day Sunday. I can take a Sunday night flight back and be in California by 11 or midnight Sunday night. So, I’m ready to go for work the next day. There's really minimal pieces of life you have to alter to get to N.C. Defcon. I love that conference. ColdFusion summit – it's in Las Vegas so for the very opposite reasons thought of fun to go to C.F. summit, there's tons of things to do in Vegas.
Michael: Yeah, I talked to Alicia from Adobe about C.F. summit's a few weeks back, and it's just incredible what you can do in Las Vegas.
Nolan: Yeah there's…
Michael: Also there's going to be ‘100s of ColdFusion developers there so.
Nolan: That's true that one… N.C. Defcon is great. It's about five different tracks, and there's a decent amount of ColdFusion content there. But as it is by no means an exclusively ColdFusion centric conference. There's JavaScript, and other mobile, and stuff going on there that's related to ColdFusion, but not specifically Adobe C.F. The ColdFusion summit is two, or three days of nothing but Adobe C.F. content. Its new features in 2016, stuff coming up in 2018, how to secure your ColdFusion applications, how to do different current techniques in ColdFusion. Like use N.B.C. libraries, or M libraries, or how to do this that the other thing with ColdBox, or wire box, or framework one stuff. And different object oriented patterns that are useful in ColdFusion. They have sessions usually on how to use the new A.P.I. manager that works that comes with ColdFusion.
It's all very, very much focused on that technology stack, that community, and it's really large too. There are several hundred people that go to the ColdFusion summit in Vegas every year. So if you go to conferences and seems like maybe the head count is lower than you're expecting to feel like oh, this isn't really a great conference, or not as many people here that do what I do is I was expecting. Maybe you go to N.C. Defcon, and you happen to be hanging out with, or near a bunch of JavaScript developers. So you don't feel like you can relate to them before you spend your time doing this ColdFusion. Go to the ColdFusion summit in Vegas, and you'll be around people that do basically nothing but ColdFusion all the time. There's a way more C.F.M.L. centric presence at that conference.
Michael: Also, if you want to talk to the Adobe staff who create ColdFusion.
Nolan: Yeah, that's true too. They're all at that conference.
Michael: Right, so great place to buttonhole [inaudible] [52:28] about some feature you wish was done better or.
Nolan: Absolutely, they're pretty receptive to that kind of feedback too. At least, I've never had an Adobe C.F. team member sort of scoff at me when I want to approach them and ask a question about hey, why did you do it this way? Or can I get a feature request in for the next version of ColdFusion to fix this bug, or do this thing. They're always very receptive to those suggestions whether they have the ability, or resources to implement all of them is an entirely different story. But Alicia, and Rakshith and all of those people are very, very open to talking to everyone in the community, and learning more about how they like to use ColdFusion in their projects.
Michael: And then, the third conference you mentioned is C.F. Camp which is in Munich Germany.
Nolan: It is yes. I'll be in Munich Germany again in mid-October for a few days to attend that conference. I've been to C.F. Camp. I think I've been three times now. This will be my fourth year. And N.C. Defcon has been at the same campus every year they've done it. ColdFusion summit has always been in Vegas. So it's kind of the same environment. They've moved hotels a few times, but it's basically the same kind of set up every year for the summit. C.F. Camp – the first two years that they did it. So this conference has been around for about five years now I think. The first two years, it was also in Munich Germany. But in a little bit more of kind of a suburb off to the side of Munich Germany, not a whole lot going on around there. And two years ago, they moved it to the actual Munich airport.
For those who don't know the Munich airport has this great big shopping mall, business center out ten feet out the front door. So you land off the airplane, get your bags, walk out the front door. You cross a big open plaza, and there's three, or four great big towers there with restaurants, and various grocery stores, and restaurants, and all kinds of things going on there. And in one of those towers is the C.F. Camp conference. They run out three or four different rooms for the different tracks. They have the expo vendor booth area just like you'd expected in the other conference, and they have all the food right there as well. Food at C.F. Camp is probably the best of any conference I've ever been to.
They have this really great spread of restaurant chef quality; fish, and potatoes, and meat, and vegetables, and just it puts the typical conference food stereotype out of being even a possibility of something you get there. So, I really like the way they just they take care of everyone there. It's a great environment. And again it's a very, very ColdFusion centric user base that attends that conference. It's not exclusively ColdFusion I would say. The C.F. summit conference is almost pure ColdFusion content. And N.C. Defcon has one or two very, very strong ColdFusion tracks. The other tracks lean a little bit more toward Mobile development and JavaScript and tool and some other things, and C.F. Camp right between the two.
So, if you do mostly ColdFusion stuff, but you do also have to touch Java once in a while, you do also want to know what Docker is about, and some other modern web development stuff. Maybe you play with Java, or Kotlin, or things like that. C.F. Camp is kind of right in the middle there for that community. And again, the ticket prices are pretty reasonable for that one. It's a two day conference. They often have a preconference day that is something one of the sponsors is taken care of. I believe one of the sponsors is usually the preside C.M.S. folks who are based in Europe.
They'll do a one day kind of show and tell of the different things they're working on and check that on to the conference as well. So you can go for two days, or three days there. And yeah, I really like it. I speak literally five words of German. I can say please, and thank you, and I'm sorry, and order coffee; and that's about all I can do. And I've been fine every year I've gone to Germany, and hung out at a conference with everyone. They're all really nice. The people in charge are ColdFusion developers themselves.
Michael: [Crosstalk] [56:29] can speak English anyway.
Nolan: Yeah, I've never had a problem doing what I need to do to survive on my Germany for a week. I can get you know food, and directions for I need to go, find the bus I need to take to get to whatever. The public transportation system there is amazingly involved too. So you can get anywhere you need to get, and never set foot in a car. And I mean three times I've never rented a car once just between…
Michael: right
Nolan: … buses and trains and taxis like you're fine.
Michael: Well, it sounds like you've got an exciting rest of the year, Nolan.
Nolan: That's the idea.
Michael: Yeah, so I appreciate you coming on the show today.
Nolan: Thanks for having me. It's always a pleasure talking to you Michael.
