You can listen to the podcast and read the show notes here.
Michaela 0:01
Welcome back to the show today we're looking at agile cold fusion API development using the amazing postman and some behavior Driven Development secrets and co box with john far. And he's going to be talking on this at into the box in a few weeks time and we'll look at why you should be used building API's and cold fusion and why I'm particularly should be using the postman and co box for doing that and we'll look in detail of what cool things you can get with postman either in the free version or the paid version. So actually, you can get a long way with the paid the free version. And we'll also look at agile development and why you should be doing that. So welcome, john. Thank you. Good to be here. And in case you don't know, john has been in the cold fusion community for millennia, I think or possibly 20 years, one or the other two centuries. That was too
you cross the other century. And he's he's been involved with jQuery and knockout and view libraries. And he brought us cold fusion framework, which we'll talk about a little bit later. So first of all, what let's talk about API's, why should people listening be building their APIs using cold fusion?
John Farrar 1:21
Well, one of the reasons as it works, it's a lot of things we do, we jump in, we don't even know if it's going to work. And we find out there, there's all these, ah, I wish I would have known but in particularly when using cold fusion and called box that technologies, they're cold fusion effect has some API stuff in it, or Lucy that both variations, but call box adds a real mature system. And, and when I talk about that, and particular way to you guys, see, if you haven't started messing with it, bots, five should be out for the show. And it has some nice enhancements along the API line.
Michaela 2:08
Yeah, I hope that's going to be announced. And before the into the box show. lot of cool things in there. So
he decided you're going to build an API. Wait, let's back up a minute. Why? Why do you want to have an API in your application to start with, what's the reason for doing this?
John Farrar 2:29
Well, historically, when we started building apps, that what we did when we wrote application says, your package everything into one box. And over time, you know, things like I said, the only constant is change. So it may go back to that it's not what we are right now. But what we tend to do is your data connector is your API. It's where and your business logic is validated on the API. But your actual application and most web applications is actually pulled right out. And all this stuff, you look at all the validation that happens immediately in the browser, that's a separate application. And that's why we've started migrating from where I used to use a lot of jQuery to where we're using stuff like view or you're using Angular Are you using react, they should stay around in spite of their privacy issues. But we'll see,
for those of you have missed all the Facebook fame that's react comes from, but they're all great frameworks. And, but I jQuery was mainly it major DOM and all the stuff you're sent to the browser, jQuery manipulated that made it work, when you pull that out as a completely separate piece. jQuery isn't written to do that, when they're together, jQuery is still in extremely viable, you're still have the option of using viewer Angular, but it's still viable. But when you separate them out, you really want to go to one of the modern frameworks, your API is that back end that's communicating with it. And an API, when you're building it, you're either doing that for part of your app, or for the whole app, because you've completely separated the two. And it's funny, when we talked about object oriented programming, one of the main things that people have said that has lasted is you want to separate stuff out. So it's focused on what it does. And then API does that you're separating that to be that piece and your front end that's interacting with a customer, they're doing that. And where I work, we basically have four teams, we have the database person, my day job, we have the API developers, we have a team of them, we have a matching team of UI developers, they're using Angular, I got there too late to push them to view their loss.
And then we have the QA team, and they're there to just shake their heads how many times they have to get us to do something, right.
Michaela 5:23
So is this part of the microservices movement or
John Farrar 5:29
API isn't microservices, although you can do something very similar to that API is usually more of a packet service where you're getting all the pieces together. And although there there is the rolling, always wanting to clarify that this is not a micro service. When people use something like Dr, which is Enterprise Service, we're considering going that way. Also, you can actually package is each these pieces separately,
and they still work together fine. And when you do that, it's nice, because when they scale, then you can scale just the parts you want. So because generally, your front end UI doesn't carry the same type of load that an API with
Michaela 6:22
that makes a lot of sense. So let's talk about why you picked code box for this because I know co books you wrote a framework yourself I Co Op, I think it was called. Yes? Why didn't you use that? Why using code box to ask when I create a direct question,
John Farrar 6:42
when I create a co op, it was referring to collaboration cooperative. And what I did is I wrote a framework, or I could use cold fusions, custom tags, and they would render that front end UI.
Unknown 6:55
So
John Farrar 6:56
as we started talking, letting these pieces up. And that type of development is becoming more and more scarce, the wind that I was providing is no longer the win that gives us the biggest one. So it stolen when if you wanted to do that. But I'm actually recommend people learn something like view and split that out. And the whole architecture framework of the coal box community, they were further along, and the API development and all of the services and extra stuff they had. So I decided community wise, when all events better if I jumped on that team, so and anyone who's still using Co Op, I still support that for them. But this is for new development, I'm recommending you go that direction.
Michaela 7:50
So what what in particular do you like about cold box for API development in cold fusion,
John Farrar 7:58
there's a there's a phrase in April API development restful,
and I'm sure some of the guys before I spoke my first conference, we had some passionate debates over what was appropriate technology and who is a and there's we all some people were saying back then who's a loser because they're not doing pure object oriented programming. And once that became more social,
we we got past the religious purists side of the thing. Because these are all principles. They're all designed patterns that make things work good. restful is a core set of principles that you if you're going to violate them, you need to have a design reason to do it, not just, I prefer to do it a different way. They're really good principles. So there are a set of best practices, not not religious things, that if you violate them, you go into code hell.
So with that in mind, when you're looking at those best practices, and a framework that setup to already think down that same pattern, or that successful pattern of things just lines right up with the route for way that cold box was set, first time I ever did a call box app was in version three, and it was routed way back them. So
they're in alignment. And some when you're hearing this as how to do it, and you have a framework that's flowing in that direction, this is a good thing, because you can put your energy into building the app, instead of design,
hacking the framework to make it do what you're accustomed to, we're being taught.
So Paul boxes, it had a lot of that stuff, pulling in number one. Number two, it's headed in that direction, or the future features. So it just, that's why I'm saying at the beginning, it just works. And you're able to concentrate on your work instead of building a framework out. And another thing is, you sometimes when something's pre built, it's sort of constraining
what my day job we're pulling, like, three or five different apps together. And it's we're doing Abdel as much as we can, but we have one rule, no features left behind.
Yeah, I'd say you're laughing, it's worth laughing. But we can achieve that. But that makes it really challenging. But even with that constraint, using code box, and the API, we have not had an issue yet it's natural, it has, it has never gotten in our way, with a feature that there that didn't help us. So it's always forward moving. So I like that type of framework.
Michaela 11:10
Well, and I know they have a whole section in their documentation about how to build REST APIs together with Cole box. So clearly, they're supporting it, as well as the new features you mentioned. so great that you using that now you're using something I hadn't come across before postman tell us what that is,
John Farrar 11:32
well, I was just, you know, creating calls and getting responses back. And I would look inside the developer tools inside of
Chrome. And that's how I was doing my development. But when I came on this team, they already have a subscription the postman and they were using postman because it has a nice UI, and they use the graphical user interface to, okay, here's the ad grass, here's the variables we're sending, we're sending this as a post, or they get a blast. And then they had a thing that showed what came back, which was sort of neat, because it was all in one interface. Plus, we could actually save these. So all these different requests, we could save them, like kinda like that, because, you know, we could eat and then I found out and this is part of the paid version, if you're doing a team that when I save that request for for reusing someone else can use that also. So we can do share all those things and build up the library. Well, since I started, they started adding things like folders so we could organize them. And the last six by no update, they even have workspaces and workspaces with SAP little collections with sub folders inside of that is the visual want. And another thing I put inside, there's environments. So I'm sitting here, building this whole thing up, and I'm running against my local dev laptop. But then we push it up to our common death thing, we make sure everything we're doing is working together, or our QA and I can create different environments. And all I do is swamp the environment and run the test against that other system. So that became very handy, because swapping back and forth being able to share with the team, this put us on a whole new level for building APIs together.
Michaela 13:39
So the issue this is solving is that when you write or consume an API, you're sending either XML or JSON, or some complicated piece of HTML. That's not very human readable now. And what this does is it lets you capture that be able to read it, debug it, see what's going on plant if you want to share it with other people. So we feature you can replay it
John Farrar 14:07
so that they added that to, and that's part as I've got in the post man that they're only I don't know, if they started in 2012, or 2014. But they do such a good job, they have over 3 million users,
Unknown 14:27
wow,
John Farrar 14:28
that there's a reason they have that many users, I hope it's not because we're stupid, I'm going to go with the other because I'm a user.
Michaela 14:39
So it's sort of like in the old days before posts, man, you were sending these packets of data, but it was really hard to do anything. Now you've got sort of like this postman. He grabs your letter, or your packet of data, and then he opens up, makes it all readable, stores away a copy for you organizes, it even lets you read a liver the same packets over and over again.
Or you can fake out dummy addresses to send, you know, to test your API against and see what's going on.
John Farrar 15:10
Well, not only is it readable, but they have three views as far as what comes back from the browser, they have pretty. So we'll take fund your XML your Jason and stack it in there. So it looks nice, where they have raw if you don't want it to touch anything, or they have HTML. And we use HTML all the time. Because when we're building stuff, well, we have errors. Imagine that. And when we have errors, and it does that dump while we can dump it right back to post man, look at the dump right inside there. We don't have to go to a browser. And we like, well, what line did that come from? Well, like when you use a dump, and CF ml or Lucy, just put your mouse over there. It'll tell you though, the dump was on.
And there you go. Go back to it. And the other thing you mentioned, one of the things we've started doing, and all this in a moment, there's deals with the Agile thing, but the UI guys in the APA got API guys are working together. So we'll have a story we're working on, we're creating API task, we're creating UI task, and they go together. But we're, we're separate, obviously, by what I've described. So how do we bring that together? Well, the first thing we do is to a UI API dB, we all meet together to discuss the story we're trying to accomplish with this ticket.
So we start figuring out, okay, what's my part was, is you I want, and you guys like it, what it and we're going back and forth on this, then UI and API meet together. And we're using post map.
And what we do is we map out, hey, what am I supposed to be sending to the API? So you is figuring that out? And I'm like, Okay, what are you thinking you're sending me? So we're actually doing this on the shared work environment? And what am I supposed to be sending back to use, we created what's called a mock of that. And if they want, they can actually hit the mark service, because post man does that also, or we're just mapping it out. So when I jump in, and actually start coding my API,
well, I can actually look at what they're expecting and write to that. But there's another feature and postman, postman will also do testing. So I can take that and store it. So what it's exposed to give back. And then I can actually write it behavioral driven test, and post man to, to whatever degree of
picking us we want to go to. And we can test it. So we write that test. And then when I start writing my code, I can pre write my unit test on doing test driven development style. I still do BDD. But But we pre write the test. And I pre write the test and post man, no, yes, of course, sometimes the tests get modified. But I've got a basic test. No, this is what's going in, this is what's coming out a test to validate all this stuff, I've got that before we even start coding. And they, the UI guy loves that too, because he knows what to expect. He's coding, this is what I'm expecting that this is what I'm supposed to be sending you. And with me, it's the opposite order. Okay, this is what you're sending me, this is what you expect back and we have that standard right out the gate. So postman is basically like turning the light on. And a phase of development, that's usually kind of murky. So you,
Michaela 19:03
you can fake out both sides that you can fake out you as cold fusion developers crew, sending that API, making sure you've got it formatted correctly and postman but the you UX developer can consume
John Farrar 19:17
the API from a mock version of the API, before we even coded it, it just like in post man, you set a different environment, all you have to do is and the UI, they just have a tab something that they toggle on flip the switch, so it knows for this feature, and this at the mock server.
And obviously it's it's going to be static Lee mocks not dynamic. But you know, it's a 200 request is that a forum for requests because nothing responded for online was an authorized all those standard things that are part of restful services, it covers it,
Michaela 19:57
well, that sounds like that avoids a whole bunch of bugs and miscommunications between team members
John Farrar 20:04
it reduce it, you get to work on the meaningful bugs faster.
And the developer who doesn't work on bugs, you can't teach the rest of us anything, because we don't program
Michaela 20:20
now what about when you've got your API live, you still use postman then for monitoring or other reasons. So Well,
John Farrar 20:29
actually, post man does have a monitoring service. So you could actually use it for that just to make sure it's or whatever type of monitoring your creative benefit solution has. But the the other side of it is, we use this because we keep changing code. And there's this phrase and testing called regression testing, because it's amazing how would change that had nothing to do with something else turns out that it really did. And if you change something over here, and it breaks something and other side you never expected. And another neat thing postman does is it walks through the test, you can even make the test intelligent, okay, run this test. And if I get this type of a response back, then run this part of the tests next, so the test aren't just a mechanical thing, you can actually build the level of intelligence and flow into your test.
So running a monitor on something like that, I have a benefit. And, and that test also can be taken offline and run with a continuous delivery bill type system like postman Travis, circle, ci, whatever. And with that, you can move those up. So I write some new code, and I don't just run, what we do is we run our unit test local, but then we'll run when we're doing a build pushed, another server will run our Newman tests there, and Newman is the name of JavaScript tool that will run your postman test. So that's what we do our validating and you know, just,
it makes stuff more visible.
Michaela 22:28
So just so I'm clear, you're using some kind of continuous integration tool, like Jenkins or case, but it's not exclusive to that it will. And then every, every time you check in a change in into your source control, it goes off and runs all these tests. Oh,
John Farrar 22:50
I don't know if it's best practice or not. But our our goal is to do it before you merge it back to the master branch. Because what you have is a master branch and you go off on a feature branch. So removing this new feature, and we have what we call it, two weeks spread. And then our two week sprint, we're trying to deliver new features. And we typically are delivering,
you know, 12 to 20 new features every two weeks. And those are minor features. We're not building major features. But what that does is it gives us that little slow continuous when and let's see, yeah, I'm going to cheat because I'm listening to an audio book right now. So I'm just look it up here called barking up the wrong tree.
And when I was listening to it last night, he talked about a lot of times, we're biting off too big a piece. And we're like, okay, and it's a concept of what's a be hags big, hairy, audacious goal. And if we set that big goal, we think we're going to win. But what we've learned in Agile, the development that continuous half I gotta win, I made progress. I'm making progress. I'm winning, that tends to keep people more engaged. And it's harder to be someone who's more engaged than someone who isn't, if you're creating a bee hag, so that you can engage, you're still maintain the self same level of engagement as someone who has that regular steady winnings solution. And that's part of what agile about
Michaela 24:32
so you've really embraced agile, that tell us what why you think listeners should be looking agile for that development lifecycle.
John Farrar 24:42
Let's say, number one, if whatever you're doing is working. It works. I don't say, Oh, well, we used to do is we were such losers, because if you think about that, you know, it's exponential way we're losers, we will lose their squared before that we were losers cubed. Now we weren't because we made products that deliver it. So what I'm looking at with agile is just a bigger win, because the markets getting more competitive. And if you want to be more competitive and stay in the flow, you have to have the bigger web. And I believe agile actually does that over water flow. And some of these other methodologies. In fact, I didn't know really what water flow was, until I learned that dial and stop doing some of the water flow things. It's like, Oh, that's a water flow is it's not bad, it's not losing. But I just for us, our team is finding a bigger web. So so. So the traditional long life cycle development is where you do all the requirements up front, and then you go away into a dark cave for six to 12 months, or however long it is, and then come back and show what you've done. Whereas now, every two weeks, you've got new features to show correct, and what we actually do. And fact they were when I started the podcast, or the rest of the team is showing, when you do agile, one of the things you do is you have what we call stakeholders and our stakeholders, they're the people who are going to be using the software or making money off it, it depends on your agile scenario, but they're the ones that will be making the investments so you get a collection of them. And every two weeks, you're showing them your progress.
They're giving you feedback when you wait six months to show people what you're doing. And they're like, I've got this problem with this one feature. And I talked about the regression testing, you have the same thing but in an explosive for,
we can redo that. But it's going to take us two months where they would have brought that up along the way
it Okay, you just put it in the flow, it rarely has a large impact when your users are meeting with you radio. So that's one of the big differences. In fact, when I get done here, we also have what we call a retrospect meeting. So every two weeks, we get together at the end of our sprint. And when we get together at the end of our sprint, we talk about two things,
Unknown 27:30
what went well,
John Farrar 27:33
and what could have gone better. And I really like that. That's the attitude and openness that creates is way different. Like, okay, who messed up,
you know, you made the whole team look bad. I did not. I just exposed you know.
So we do in one of our rules for our apps gel team. A lot of teams have adopted this is if you're not having fun, you're doing it wrong.
I never heard that. And waterfall. I guess they could make that up. But one of the things is it is actually working. So like will do things like we name our sprints or two weeks France and right now Center at every two weeks. This is the F week because we're going alphabetically and we have themes. So last spread was named Einsteinian because it was he and someone had to pick a chemical element and that's reactive chemical element. So the whole time during the sprint, we had to put up with Einstein puns and plays. And so this time it was AF and and it had to be something from IKEA. Now we have a random category and someone from the team is baking. So they picked factor that's not little blue bag at IKEA. And since we're an expedited transportation company, that that word fractal means transport so that it was my turn to destroy the sprint planning meeting, which we have on Wednesday. So I opened up the meeting with upon I said, Okay, I'm going to destroy this one, I'll get the first pot and they're like, Okay, this is their sprint is on the bag. And they're like, okay, one guys, like I'm leaving. Now, he says, I'll be back in a week.
And then they were complaining at the end of it, because we've had more points than we've ever been near likely. This is scary. And of course, someone had to throw out the pun, you know, if this is too many points, we could just spend another five or 10 minutes and refractor are bidding.
Well, we. And we try not to let that interfere with the flow. But no, we're we're having fun. In fact, because it was IKEA. When our stakeholders came, we had Swedish meatballs. And during the presentation, yes, we did, we shot a video clip of a Swedish chef.
So they're getting what they want, they can see the traction, it creates a whole different spirit. But and I will warn you, when you first jump into it, it is so foreign to how most people do development that you don't get a lot of traction that first or second sprint, and you're like, oh, we're losing traction. But once you start getting it, it's a whole different flow. And what you do is your team actually starts learning to work as a team you in the team thing just goes way up. And there's a whole lot less supervision. Because when you're doing agile, right, supervision would get in the way,
and it sounds, but just research it.
Michaela 31:09
That's why you don't, you don't have a manager like that pointy haired boss that deal but often dealt with, you've got a scrum master who's there to facilitate the team and remove roadblocks. So not my boss is the project owner. So we we laugh about that. In fact, he used to be one of the guys in code and he'll with some, he'll make a change once I will
John Farrar 31:31
get out like, get out of the curtain.
Michaela 31:36
Now, I people might think that having fun while you're doing software development is like a waste of time. But I'm wondering, does that lead to some of these other benefits that you get better teamwork, and maybe people are able to solve problems better because they're, they're not worried so much about being blamed. They know it's all you know, a more lighthearted endeavor. Here's some of the things I've learned
John Farrar 32:03
when the bosses over saying you, okay, how you doing, how much progress you're making, how much progress to making, what what you have is guys that will sit there literally for one to two hours with a problem that they don't want to share or working on something because I don't want to interfere with someone else's workflow, and then tell the boss like, couldn't get my stuff done, because john was bugging me. So that spirit of cooperation just isn't the same to begin with. And if you're stuck in something for a half hour, and you've got a question, we pop each other, it doesn't matter. If you don't know. Well, let's learn it in the next half hour, instead of spending two hours trying to learn it, delivering it and having code review, kick it back. That's just not productive. And a lot of those things that we don't actually realize are part of the classic work flow, because no one will admit that that's what they're going through.
But let's see what is Hippocrates went known for medicine, but you know what else he was famous for cold fusion
Unknown 33:12
coding.
Unknown 33:13
Now,
John Farrar 33:16
he was famous for, for acting. Oh, that's why we have the phrase hypocrite because they had these masks they would put in front of their faces, all the actors back then hypocrites. Well, most developers, when they sit, they don't want to admit they're struggling with something or ready to join his acting Guild, because they're hypocrites.
But that's one thing agile has. And we didn't have that problem with the ego. But we didn't have the engagement and one of these classic historical things. And that dial is you want to make sure that everyone local in the same building so they can interact. But we're using zoom, we're using slack with a video chat services they have. And we're using Visual Studio code on the API side. Have you heard of live share yet
Unknown 34:19
now,
John Farrar 34:21
one needed to their private beta on Microsoft right now. But it's really cool. We'll be sending coding and I'll call someone up on slack. Or they'll call me and like, okay, I can't get this code for you that I know it's right there. But there's no need for me to burn time to. And it's also that magic when you ask someone else something, the question, the answer comes to you. That's another reason we do that. But what you do is you do a live share and Visual Studio code, and the other person gets a URL. And instantly they see all your code, you're sharing the code, just like a Google Google Docs session, but you're sharing the code. And if they want to go looking at something else, they say it so it's an interactive editing session instead of a screen. Let me have your mouse let me take the mouse back. You're both so What colors do you use in your editor, you like the light screen? Do you have psychedelic colors, or you have vision problem and your stuffs all big, it doesn't matter when you share the code, they get to keep their UI, both Aaron the code and you can see where each other are creates that whole peer development. Now, we don't do pair development full time. But anytime we catch some struggling, we're like, pair up instantly pair up. And that really has accelerated what we're able to deliver speed wise.
Michaela 35:52
So you do do some pair programming as part of your agile as well as doing code reviews.
John Farrar 35:58
But we're also i'm not local, and we haven't found that to be a problem. So in fact, we've, we're letting more people work from home or the weeks
Unknown 36:11
Well, that's a great thing.
John Farrar 36:13
So and we actually, and I've monitor this, we communicate more now than we were all in the office, there's more communication, more productivity, something's working.
But that breaks the classic when you'll be taught agile, you're probably here, you need to be in one place. But that's not so true anymore.
So you mentioned earlier that you're doing behavior driven development, how does that tie in with all this, basically, that's just a way of writing unit tests, or your integration test. And when we write the test, and post man, I, this is my way of looking at it, I could be inaccurate, and the that's part of the joy having fun. If I'm an accurate, we'll have fun with it. But this is how I look at it, you have unit test, which means nothing outside of this unit can influence or create what we call a flaky test.
And you have integration tests, that's when you've got two things working together, and you need to make sure they work together a unit, you mock those things outside.
So when we do our postman test, that's what I call an into end integration test. Now, I know we're not doing the UPI its end to end API, so we're hitting it, everything runs up inside, it comes back, and we make sure we have a proper response. So to me, that's into end integration, instead of a partial integration. But those are all integrated, where's the unit nothing outside of here, my actually testing only want to know, the lines of code that are unique to this unit are all being hit without failure. Now, sometimes you'll take it beyond that for testing specific logic. But the main goal of unit testing is knowing you can flow through your code without without a line of code that would never run
and behavior driven development is when you look okay, what are the critical issues because you have critical issues, you have important issues, and then you have stuff that really why did you test that?
It's like, why would you test cam cold fusion at one plus one, you don't test that, that's, that's a dumb test. So
you're writing the test that actually add meaning. And all of us have a limited amount of time. So So you've got to determine where is your gain and loss. And because all these things tester being stored, whenever we put new code up all the old test run against it.
Michaela 39:07
And the crucial mindset difference with behavior driven development is you write the tests first, before you write the code. Is that true?
John Farrar 39:16
Yeah, it's partially true. It's also how you write the test. Because the personality of a test is when you ride a classic unit test. And they're both actually unit test. But a classic unit test is, okay, I have this thing that I'm going to pass them to this component method, and I get the results. And I want to say, did it give me this answer? Did it give me this answer? And you just basically, it's like checkbox testing. When you're doing behavior driven development. It's like writing a story.
So okay, I have this component that
sends out emails when an order is made.
And then down inside, when I send the correct a correct email address,
then expect
the email to be sent. So we're doing a story here.
Whereas if you're doing unit testing, it would be here's the name of this test, email send. So I call the method and I say a cert email was sent.
And it's sort of dry.
So the reason it's called behavior driven development is because we're talking about the behavior you're actually writing stories. And there is even a alternate way of doing it that is extremely story oriented, but and test box will do both of those versions,
which is the testing framework that works with coal box APIs.
And when we're doing behavior Driven Development style code in our post man test, also, oh, okay, we're doing that both sides it's slightly different. We started before they're some of the updates they had. So we're using an extra library we pulled in and we're using the child JavaScript library for what we're doing but it's very little difference
Michaela 41:30
so I hope your toolkit into the box on all this goes well, that sounds like a really exciting topic I just want to change gears slightly now and and ask you why are you proud to program in CFL?
John Farrar 41:45
Well, it used to be because it's been around so long in fact I have two sons that have followed in the software development one of them Stone Cold Fusion and the others and I Renegade tech ology dot something
seems like a dots the end of a sentence in the law, your name your technology dot anything. But
But here, he asked. And I looked it up. And do you know that Java, PHP and cold fusion, we're all created the second year,
Michaela 42:24
I knew they were pretty much the same age, I didn't know it was exact.
John Farrar 42:27
Yes. Don't net the youngster. Right. Same age. So apparently, that was a year for durable technologies. Yeah, I'm thinking is cold fusion has stood the test of time, number one, number two, I know, confusing piles into Java. But I know a lot of Java developers who have chosen cold fusion because they don't want to get down into the granular stuff. When when you write Java, your packaging stuff, cold fusion has a lot of stuff, package stuff already for you. But you can still reach out land the job at Intuit if you want to perfect cold box has a few libraries that it reaches out and does that same thing, including command box. And for a while I was felt the pull away because all these other guys were getting these package tools, command line tools. And I'm going to give credit here Brad would put together a thing called command box. And we have the same type of thing and our community that they were getting. And it's an absolutely amazing piece of it just changes the whole development. If you if you're in cold fusion, and you haven't tried command box, I'm not at all Shame on you. It's okay, if you're missing out. But I'd like you to not miss out. Try it is free. And there is no commercial version. Right? You should have made money unless it's good.
Michaela 44:02
It is amazing. So speaking of prices, that the postman thing we were talking about, that's free up to a certain number of users per month, right,
Unknown 44:12
right.
John Farrar 44:14
Well, actually, it's free for one user, that's, that's your number. Yeah,
I will go look, let's see,
Michaela 44:23
he's free up to 1000 API calls a month, something like that, right. And that's pretty hard to hit. So post
Unknown 44:30
man.
Michaela 44:32
And then it's only like, eight, $8 a user a month beyond that, it's a knowledge they need to go, which is reasonable, very reasonable,
John Farrar 44:41
especially with all the features and you can share if you can't, if you have a team, and you can't say $8 a month,
Unknown 44:49
they're not using post man. Right,
Unknown 44:52
right.
John Farrar 44:54
So no, I that's one of those things that absolutely pays for itself. And I am going to mentioned this at the show. If I remember, during my session, someone may think that I'm pushing postman because I get affiliate or something like that I don't get squat from them. The only thing I get from them is a great product. And if you guys started using it, you can kick back ideas my way and its communities. The reason I'm promoting it, because it is a very social solution. So
that and by the way ahead, you can do private and team workspaces. So and you share the things across work, it just,
I almost hate it. Because I have a reputation for coming up with new ideas that people could add. And the software and post man has done so good at adding stuff. And they're like, wow, that's one of the things I like to do. And it's hard to do, because it does so much
Unknown 46:00
market
Michaela 46:01
rate. So what what would it take to make cold fusion even more alive this year,
John Farrar 46:09
oh, when I look at making cold fusion alive more, unless I've been talking with a number of other developers about actually putting together a CFL online school. So along the idea of Larry cast, that's one of the things I'm looking to accomplish. And, and another thing, basically, I think a lot of what it takes to get alive is to look at a project and what actually gives you traction because there's a lot of people who are still using cold fusion, and they're using it
Unknown 46:49
the way we did 10 years ago.
John Farrar 46:52
And we've learned stuff, things that help us so we can help them learn some of the ease of the systems we're putting together. The, that's half of it. The other half of what I think it takes to really help us to get alive is for us to start putting out solutions that are based on it that pull people in, because new people coming in. I mean, that's what we're getting a cold command, mops and stuff are answering those questions, they're making it easier for people to come in. So more of what I'm thinking is we we just need to keep doing what we're doing. Because although we didn't have it in the past, I think we have momentum, we have the right products there. We just need to get more more people aware that not only does cold fusion work, but we have command box we have cold box. These are very competitive, mature, functional, this stuff works with Dr. So there's no you can now host about anywhere. You don't even have to find the cold fusion host anymore. Things are changing. So I would say just be awesome at what you do hold the reputation because I think fusion over the last year has actually changed. And I don't know if you've heard this, there's a side note there. A lot of people thought cold fusion is that it was dying. Remember that?
Michaela 48:23
I do remember it. That's why one of the reasons I started the CFL light podcast because I just want to get the message out that it's alive growing and and what can be written as a modern used as a modern language.
John Farrar 48:35
You know, the cold fusion his dad was actually a myth and false yes,
Michaela 48:40
I do know it's been a myth for the last 10 years you know where we found out what it was oh go ahead tell me
John Farrar 48:47
you have services like built with no way that they check and they showed cold fusion was going down and down and down less cold yeah
then we found out that they have a algorithms they're using to find out what a site was built with and they used to look for dot CFC or dot c FM Yeah, we're using routed servers now which don't put that anywhere Yeah, so there was no indicator beeping This is a cold fusion psych. So Adobe's even mentioned that cold fusion their market share has continued to grow but sites like belt with can't detect it so they're claiming we're shrinking and they're just wrong and we love them anyways because they say information they just yes nobody is right all the time
Michaela 49:44
yeah I unfortunately I do know about the built with issue because I spent about six months corresponding with their tech support trying to convince them that they're doing it wrong and here's how to do it right
Unknown 49:57
they didn't quite get it
John Farrar 49:59
I would tell us what they're built with we could write the code for them
Michaela 50:05
you go well it's founded by some guy in New Zealand I even tried to hook up with their
see CEO to see if I could convince hear me you know cuz sometimes in companies the tech support doesn't sound so early morning
John Farrar 50:20
k well Erica all other southern America's will get this plus their heart
Michaela 50:33
But yeah, I know that Brad would was successful with one of the other companies that monitors different technologies so you know the race hope
so what are you looking forward to this year's into the box conference? JOHN
John Farrar 50:51
what I'm looking forward to is I've got my feet wet and doctor but I I don't want to go on a long swim
and I'm looking to roll my stuff that I my personal sites and stuff I do for others and hopefully a company I'm working at. I'm looking very excitedly at what Dr. provides in the container. ization and I
so I'm doing a day early and I'm going to pay my way to go to the container sessions
Unknown 51:28
for the hat is great. And yeah,
John Farrar 51:31
and there's also another speaker who's doing some Jenkins integration in particular. I'm looking forward to that session.
Michaela 51:41
Yeah, I did an interview with Mark drew all about, you know, doing Doc, right. And that's the session you were thinking of going to. But this is not the session that day class before john, I'm okay. The whole debt the full day one. Yes, a lot of those that are already sold out, I think.
So it looks like a great event. And it looking they've got far more people registered already. We're still a month away from the event. And I think they've got more people registered now than came last year. So great,
should be a great event and a chance to enjoy Texas hospitality.
John Farrar 52:20
That's why I was in the Navy. So three hours later. So it's for me, it's good to get back in the Texas because I enjoyed my time there.
Okay. So if people want to find you online, what's one of the best ways to do that? Well, my sites are being flipped at the moment, because I'm pulling them now into the coal box and everything and but so sensible dot com is my core site, but my coding site is so last s o s AP p s dot com SOS apps. And that's, I like that acronym is because I like servant oriented software. Ah,
Michaela 53:01
excellent. So we'll put those links together with all the cool stuff you mentioned today. And the transcript from the show notes together all on the show notes page at the Terra tech site and thanks so much for coming on the podcast. Good to be here. Appreciate the opportunity.
