You can listen to the podcast and read the show notes here
Michael Smith: Welcome back to the show. I'm here with Luis Majano and he's the CEO of Ortus and all things Box. He created ColdBox and CommandlineBox and TestBox. I don't know. All kinds of things. If it has ‘Box' in the name he probably had something to do with it. And we're going to be talking about Behavior Driven Development. Why we should be doing it. Why it's different from Test Driven Development. How TestBox makes both easy. And we're going to look into some of the semantics of that.
And then Ortus is also doing a Keynote of this conference and why you shouldn't miss that. Going to look at some of the roadmap stuff. What modern ColdFusion development is. Addressing the issues that companies adopting ColdFusion have with language shaming, modern tools, and sometimes it being to hire good ColdFusion developers. And the driving force behind all things Ortus.
And I managed to get Luis to tell us a little story about how he came to the brink of moving to Groovy and why he came back to ColdFusion. This was a few years back.
We'll also be looking at Behavior Driven Integration Development, because he's giving a workshop on that, and how it's different from Behavior Driven Development, which got my head scratching for a bit but we're going to make it all clear in this episode. And why you should be doing it and how to implement it first.
And then finally we're going to wrap up by slaying the ORM dragons with CBORM. And why ORM is sometimes seen as a dangerous dragon and how you can tame it.
So welcome Luis!
Luis Majano: Thank you. Thank you for having me Michael.
Michael Smith: So excited by the Into the Box conference. There's so much cool ColdFusion stuff here and it's not your first ColdFusion stuff, this is all modern stuff.
Luis Majano: Yes. Definitely very very excited. Over 28 sessions, it's just really, really exciting.
Michael Smith: So you're doing a whole day on Behavior Driven Development. So what exactly is Behavior Driven Development?
Luis Majano: Yeah so I'm doing a workshop pre conference. We have a set of workshops and I'll be leading the Behavior Driven Development workshop.
So Behavior Driven Development is an evolution of Test Driven Development, so it's kind of show casing people …
Michael Smith: I was wondering about that.
Luis Majano: Yes. It's an evolution so it still has its roots obviously in Test Driven Development, but more addressing …
Michael Smith: Just for the folks who aren't doing Test Driven Development, what does that mean?
Luis Majano: Sure. So if we start with Test Driven Development then we can evolve into Behavior Driven Development. So Test Driven Development is basically a process that developers take in order to build their applications where we start with a test first. So we start with the development of a test scenario. Usually with Test Driven Development we're very focused on the low level right? We're focusing on components in our language and CFC's and mostly on methods.
So it's very developer oriented and it's very, very, I would say, very geeky. Right? And we're always focusing on functions and if these functions work. And then if that CFC has other dependencies, like other components, then you rely on mocking techniques to be able to control environments. Sometimes these tests kind of become stupid. You know, they're one liners that you have to be mocking all the time.
And usually with test driven developers, developers really give up. It's really not fun. That's the truth. And it's tedious. And sometimes when you have big object oriented applications it can really be daunting to create all the mocks, and sometimes you're just testing an ‘if statement' at that point. So it can be really dumb at that point.
And then the output of these tests are also very geeky. You know, I can't take the output of all my test driven reports and show them to a client and say “Hey. Look I have finished all your requirements.” It really doesn't happen right? So it has its issues. It has its problems. It has its benefits, but it has its issues.
So basically what Behavior Driven Development does is take TDD to another level. You still have a process in play. You still start with your tests, but this time we're going to call them, in kind of agile terms, we're calling them specs. And it goes through now looking at software as a whole instead of looking at it as just how you're going to build it in a component. Most of the time it's never one single component and one single method in order to have a requirement like “I want to sell a product online,” that usually would involve many components, many functions calls, and that actually is what gives us benefit when we have these requirements.
So I'll take you by the hand and kind of show you how you can digest real world problems into agile stories, or behavior stories, and how to break those down further into test specifications, and then how to use frameworks and tools to actually test them.
Michael Smith: And are those similar to use cases or?
Luis Majano: Exactly yeah. So it's taking these use cases, which really are your acceptance criteria right? If those use cases are met, that usually means that you've done your job right? Which is not something that you can say with testing methods on a component. It really doesn't happen.
So it's just showing the subtle differences there and just kind of hoping that these developers have a paradigm shift on their way of thinking about testing. Because you always see, and you always hear this, is that “Testing will slow people down.” Right? “We don't have time for tests.” And “This is going to add so much …”
Michael Smith: Oh, they have time for the bugs though.
Luis Majano: Exactly. So it's such a misconception. The reality is if you apply these techniques you will code faster, and you will be more efficient and your quality is going to increase. So it is a total lie when people say that testing will add more time for you because the reality is that the time that it adds is when you don't know it right? When you don't know the techniques. When you don't know the tools. THat's when, obviously, you're going to spend more time because you need to learn that. But once it is second nature and you can apply even automation techniques at your work station you will fly. You will definitely fly.
Michael Smith: And just to be clear to people, this is writing the tests before you even write the code?
Luis Majano: Correct. Yes. And it's kind of a side by side thing basically.
Michael Smith: And how is this speeding up the development? Is it because you think through what you're going to code because you had to write the test first so you write the code better to start with?
Luis Majano: Yes. I mean you would be surprised how much your brain exercises what you're going to be building once you start looking at the different scenarios of how to fail your code basically. So it's a lot like reactive programming. You are being reactive of what you're writing instead of at the end of the day you write everything and then you hold back and try to write tests.
So it really promotes the developer to think ahead. And in stead of going through many iterations if you weren't doing this, you do them faster because of that. And your quality obviously increases because you get that immediate feedback. I mean I don't need to build a UI in order to test my services. I don't have to do that. I don't even need a browser, I can just test with my IDE and my console. So those are great techniques.
Michael Smith: So if you're doing Test Driven Development or Behavior Driven Development, how does TestBox fit in with that?
Luis Majano: Yeah so we created TestBox quite a few years now and it's still very active development and we have lots of roadmap for it, but it is definitely a dual testing engine. First of all we had a huge investment before into MXUnit which was pretty much the only testing framework in CFML. So it is compatible with MXUnit 100 percent, or let's say 99.8 percent. But we already had a huge investment in test cases that we didn't want to rewrite and so they'll still run in TestBox. And then we wanted also to bring over the Syntax for BDD.
So TestBox in itself is just a tool to help you do BDD. It won't do the BDD for you. You have to apply that still. We're just bringing the Syntax in order for you to do it. Which is basically what any testing framework will do is bring you the Syntax and the right tools in order for you to apply these techniques.
So that's what TestBox is. It is what is referred to as xUnit framework, which is for Test Driven Development, and a BDD framework for Behavior Driven Development.
Michael Smith: And then in this whole day workshop you're also going to be looking at some of the semantics of Behavior Driven Development[inaudible 00:09:30]
Luis Majano: Yeah the first few sections is really also having a conversation with folks and demystifying the whole concept of testing. And really taking them by the hand and showing them what is the difference between TDD and BDD, how to apply to BDD, and doing exercises on breaking down stories into specifications. Then finally introducing them, not only to things that you can do outside of TestBox such as; code reviews, static analysis tools, load testing tools. So giving them more weapons for their arsenal in order to be prepared. You know, destructive testing, penetration testing, sometimes people forget about security right?
Michael Smith: Yes. Unfortunately they do. In our recent ColdFusion state of the union survey I think 2 or 3 percent of people … No maybe it was more like 5 percent had a penetration in the last year.
Luis Majano: Yeah. So it's really really important to have these things in place so we talk about tools to help there, and talk a little bit about mocking as well, and then really do some hands on applications for them to actually get into the habit of testing.
And also a day is really not that much in terms of hours for them to train, but usually I try to throw in some automation in there for folks. You know every class is different, but if they're sharp usually we end up doing something like Jenkins adding some continuous integration portions so people can see how they can actually apply continuous integration into their workflows.
Michael Smith: And for people who aren't doing continuous integration, that basically means that every time you commit a change it reruns all those tests that you've created.
Luis Majano: Exactly. Yes. So we give them all the tools for them to apply that in their businesses and Jenkins is usually easy enough for us to set up on their machines using CommandBox so it's really easy for them to start with it and just start with something, you know?
Michael Smith: Well with all these automated behavior driven tests running you're making it very hard for bugs to stay alive.
Luis Majano: Yes. Definitely. At the end of the day we all know that bugs really cost money right? And sometimes when people don't see that dollar sign, with the bugs is when they get scared about it. We even go through some graphs, some real statistical analysis, or how painful those bugs can be in your pocket. Especially if you've did this I think that the spec is about maybe 100 to 200 times as costly if you introduce testing after release.
So hopefully that will scare people in knowing that they will pay for it.
Michael Smith: Yes. Cool. So let's move on to the Ortus Keynote. So why should people not miss that?
Luis Majano: Yes. We're very excited this year to not only do our product roadmaps, which is kind of what we do in our Keynotes, but I think we wanted to come a little bit with some inspiration for developers on how we're building all these tools to modernize CFML. I think CFML and ColdFusion in general has gotten a bad reputation as of late in the last few years in terms of calling it maybe a non-modern programming language. I was going to say framework.
But we've got into topics about language shaming and how sometimes a developer feels shame of saying that they're still doing ColdFusion. And how to bring about new techniques that are not really new because we've been using them here at Ortus for a long time, but just expanding and evangelizing these tools and how developers can really modernize and not be ashamed. But hey, we're up to par really with other languages in what we're doing.
Michael Smith: I would say we're beyond par to other modern languages.
Luis Majano: Well yeah beyond. I mean we're doing container strategies, CLI tools, tasking, embedded servers. I don't think anybody in any language has done the amount of work that we've done in CommandBox in terms of embedded servers where we are to the point of what we're calling JVM Containers. And we're going to be showing a roadmap on our strategy moving forward with CommandBox in the future which really introduces a lot of JVM orchestration for containers now.
So we are really pushing forward on the JVM, in terms of embedded servers, more than any other programming language out there. So I think that's our focus of our Keynote is inspire people and show them also the hard reality of why developers don't want to do ColdFusion. Which is what we all see.
And sometimes the concern is “I can't find ColdFusion developers.” And the reality is that most of these shops, through even personal experience … I remember an old employer they hired this young guy, very sharp, and in a week he left. And mostly it wasn't because of the company, but it was mostly because they were six versions behind in ColdFusion. Their processes were so antiquated, procedural programming. And this is the issue, is that a lot of ColdFusion shops nowadays are not modern. And the reality is that young folks, young developers, will not go there. They will not touch that. They prefer to go into more ‘hip' things like MPM and Node.js because they are companies that are doing these more hip and more modern tooling. So the reality is that these companies using ColdFusion, they have to modernize. If not then they will basically be extinct and they will not get new developers because no one will want to go work with ColdFusion 8 or ColdFusion 9, or even ColdFusion 10. Nobody will want to go do that.
Michael Smith: You'd be amazed how many people are still using ColdFusion 9. It's frightening.
Luis Majano: It's crazy. It is frightening. And that's one of the big issues that I see is that corporations need to evolve. If they do not evolve …
Michael Smith: I mean that's now four versions old and its gone end of life. Any security issues with it are no longer hot fixed by Adobe.
Luis Majano: Yeah.
Michael Smith: It's like running a car that's 30 years old and full of rust and praying that the brakes are going to work today.
Luis Majano: Exactly. And I think that lot of these companies they say “Okay. We're going to move away from ColdFusion because it's not modern.” But the reality is that they're moving away because they just don't want to re-modernize. And they are going to have the same issue if you move to Node or PHP because they're going to be in that same rut. So it's really a corporation problem too that these corporations really need to invest in themselves. And every so years they have to move forward. They cannot stay where they are. And I think that's the biggest issue that we see.
Michael Smith: Well I think staying where you are, it's like running up an escalator. If you think you're staying where you are you're really going downhill.
Luis Majano: Imagine not patching Windows, what would happen right?
Michael Smith: Yeah. Not good things.
Luis Majano: Not good things. So that's what we want to talk about is how you can take these stories and all these tooling and really make a case for yourself in corporations that are running ColdFusion code that is 10, 15 years old that is procedural and legacy, and most of the times they end up moving to other languages because they feel that they're not modern enough, but the reality is there is a lot of modern tooling for ColdFusion.
The issue is implementing them right? And we'll even have another Keynote the next day on how to do that. How to tame what we call the elephants. How to make them dance. How to make those elephants dance and orchestrate them into modern times.
Michael Smith: That's amazing. And you know ColdFusion is still a great language. It's powerful. And giving it a modern face and having modern tools and techniques gives it a whole new lifetime here.
Luis Majano: Yeah. Definitely. I think that the language is great in my opinion. Obviously any language has its drawbacks and its issues. Any language has that community and everything. But I feel as productive as I would, maybe even more productive in ColdFusion than any other languages sometimes. Obviously I think that nowadays you cannot be a one trick pony. You have to have more languages under your belt. It really just make things better for you.
You know sometimes ColdFusion is not the solution. Sometimes I have to do maybe some real time programming or distributive programming. So there's always tools for the job, but for me what we do here at Ortus ColdFusion it just serves such a tremendous purpose.
Michael Smith: So tell us, you said a few years ago you “came to the brink of moving to Groovy and leaving ColdFusion but then you came back.” What happened?
Luis Majano: Oh yes. I think that Ortus was still very young in its infancy and at that time I think ColdFusion 9 was about to be released. And I think there was just so many issues with the language and obviously it was just a proprietary language at that time. I just didn't feel like it was of my benefit. So yeah, I remember my old employer we had … I was the one rounding up the folks to move to Groovy. Another JVM dynamic language. Went through the full disability case studies of moving to another language. The frameworks we would use. The libraries that we would use. I was starting to port ColdBox already to Groovy.
Michael Smith: Wow.
Luis Majano: The only language last time was Grails, which Braham [Rohashir 00:19:35] was the one in charge of it. So we had already a plan of attack to really migrate and jump, but that time is when the Railo folks decided to open source their engine. I think without that happening and the introduction of Hibernate into ColdFusion I would have left definitely. And I would have moved into more of a Groovy stack.
Michael Smith: Wow.
Luis Majano: So I'm glad they made those choices. I'm incredibly glad that there's an open source solution for CFML, not only a proprietary one. And that we have tremendous integrations with Java nowadays that we didn't. That really was what kept me from moving.
Michael Smith: Cool. Well I'm glad you're still here and bringing fresh life into the ColdFusion community and all these tools. So I know you're also doing a session on Behavior Driven Integration Development. So how's that different from Behavior Driven Development?
Luis Majano: So this is a very cool session. We're doing it with Eric Peterson. So it will be myself and Eric. I will be doing the first part which will be more theory. So I will be good cop and he will be bad cop in that sense. So I will be doing the theory of Behavior Driven Development. Showcase people the difference between TDD and BDD.
And then Peter … Uh Eric will actually be showcasing the implementation of it. So he'll be showcasing several tools such as Integrated, which is kind of Selenium like but in code. We also will be showcasing WholeBox integration testing and really demystifying how to apply BDD in modern times.
Michael Smith: Cool. So I'm still not clear when you put that integration into behavior you've got Behavior Driven Integration Development. Does that mean it's a higher level?
Luis Majano: Yes. And I think that's one of the misconception, or things that are very difficult for developers to get into when doing BDD is that most of the time when you do BDD you need to do integration testing. You need to be doing more real life, top down testing that CMC, Unic, mocking testing. So they kind of go hand in hand so we just wanted to do a play on words there to showcase the importance of both aspects.
Michael Smith: And then, why should people be doing this?
Luis Majano: Like we discussed at the beginning on the workshop I think that you would be surprised, maybe I don't think you'd be surprised, I think you know the lack of testing in applications is incredible. I mean incredible. When you go to major corporations that their software is their bread and butter. It is their sass. It manages millions of dollars for them, but they do not have automated testing systems. It blows my mind to see that and it's scary, and it's very concerning. Sometimes corporations do not see how at risk they are of introduction of bugs. And they spend so much money on bug fixing, patching personnel when they could attach a testing workflow to their environment to produce higher caliber and code quality.
We even have a tool right now, that actually Brad did with the Integral guys, which is code coverage. Most of these corporations have no idea what type of code coverage to have in their tests so it is, for me, really concerning that corporations that base their selves on this software that they build and have no tests.
And this goes for any language. Not for only ColdFusion. It goes for any language.
Michael Smith: So code coverage would mean have all the lines of code being tested right? Or you have big black holes in the code that have never been tested at all.
Luis Majano: Exactly. So we did a project with the Integral guys, the Fusion Reactor guys, and they have all the machinery inside a Fusion Reactor that talks to TestBox so you can actually execute your test suites against your source code and activate this in Fusion Reactor and then in TestBox you can get a report of all the lines of code that have not been executed in your test cases. And you can even have a code browser that you can actually browse the code and actually highlight and see which lines of source code have not been addressed.
So it really will open the eyes of folks when they run a test suite and their coverage is like 10 percent, or something like that.
Michael Smith: And that might either be because they haven't written enough tests, or it might be they have dead wood in the code that is going to never be run?
Luis Majano: Exactly. Yes. And you discover a lot of things. I mean when we did this tool we ran it against ColdBox and actually Brad started a, I don't know if I would say a poll, or started a bet to see who would get close on terms of percentage on the first iteration we did a few months ago. And I won. So I'm glad to say.
Michael Smith: And what was the answer? What was the percent?
Luis Majano: It was 84 percent on code coverage.
Michael Smith: That's good!
Luis Majano: Yes. And after that we actually realized there was a lot of dead wood, like you said, that would never be tested because it was old. You know CF legacy engine information. There was bug reports that were outdated. So it really discovered a lot of things. And our goal for ColdBox 5 is to hopefully reach that 90 plus percentage.
Michael Smith: Yeah and the problem with dead wood is that it really screws up your maintenance because you're going through trying to fix stuff and you run into code. You do a search for something and you turn up something, but is it really being run or not? I mean it's a headache.
Luis Majano: Yeah. Exactly. But without something like that to tell you we would have never found out actually.
Michael Smith: So lets move on to slaying ORM dragons. Why do some people see ORM as being surrounded by dragons?
Luis Majano: Yes. I think I always make a play on words with ORM with dragons and all these things because it really scares people away. I think that ORM's look like these untamable dragons and just too much complexity for folks. But the reality is they're not. They're like these nice cute pink ponies, but people don't realize that. So in that session I kind of demystify all those things and also apply a strategy for it. There are ways to get into it and if you have a strategy to apply, just like any other tool, it really can make you successful.
I mean we can honestly attest to at least increasing from 30 to 40 percent our productivity due to using ORM. It really explodes in productivity. But it is a tool. It's not meant to be used for everything, and that's why sometimes people fall from the wagon because they feel that they have to use it for everything. And that's when they fail.
The other failure is the defaults. There is many knobs and turns in performance and a lot of people say “Oh the ORM is just horrible at performance.” The reality is that we run it on all our systems and our average JDBC times are in the 30 millisecond range. So it can be extremely fast and distributive.
So I try to really demystify these things. We also do a 10 steps of how to apply a good strategy with ORM, and then we actually showcase all the different tooling we've built around the ORM. So we have our own module called the ColdBox ORM Module which really extends Hibernate more than the native ColdFusion functions give you.
So this we'll make actually work with the ORM fun. And this was inspired from GORM from Gray [Olstrom 00:27:59] Groovy, which really allows you to have dynamic methods, DSL's for implementing queries. We even added the ability for you to get the exact sequel queries that the ORM was going to produce so you can actually do explain plans and optimize and improve your sequels. SO we really have done a big effort there and we've gone to the extent they we're going to be helping out the Lucy implementation of the ORM. So we want to be helping the Lucy guys in the direction of the ORM extension, and right now we're even in the process of getting it upgraded to the latest Hibernate and how we're going to be working side by side with them to really push it for ColdFusion.
Michael Smith: So were you fighting with these ORM dragons earlier? I noticed you had a little bandage on your hand there Luis.
Luis Majano: Oh yes. This is ORM right here.
Michael Smith: Yeah. ORM dragons. Be careful.
Luis Majano: The ORM dragons. Yes. No you definitely fight with the ORM that's for sure. It's a love and hate relationship.
Michael Smith: Yes. But you should see the ORM dragon after this fight. It had to be carried away.
Luis Majano: Yes.
Michael Smith: Well great. So let me just switch gears now and ask you, why are you proud to use ColdFusion?
Luis Majano: I think that it's such a dear language. I remember the first time I worked with ColdFusion I really hated it, so it wasn't a love relationship at the beginning. My background was computer engineering, mostly hardware engineering, so my native programming languages were assembly, microprocessor languages, and very low level C and Java. So starting to work with Web and ColdFusion I hated it. I was like “What is this? I can't compile. You mean I just don't have to compile?”
I mean it was very daunting at the beginning, but I think I really love how the language itself is an amalgamation of so many things and how it makes me really abstract Java. I love Java Virtual Machine, but obviously there's so many intricacies and it has evolved throughout time, but having a dynamic language is what I love about ColdFusion. I think that if I were to move into other languages they have to be a dynamic language. I don't think I could go back to static. I think that there's so many things that you can do with a dynamic language that you can't with a static language.
In that sense I feel like ColdFusion really gives me a boost, especially being with it so many years that you know all the ins and outs, and even helping now with the open source versions in terms of the guts of it is great to see.
Michael Smith: It is amazing, and I talked with [Gert 00:31:01] a few episodes ago and they are doing amazing things with Lucy. I mean Adobe is doing amazing things with Adobe ColdFusion too so it's great that so many different people are working on it.
Luis Majano: Yes. I agree. I think that for us since we have to create frameworks and tooling for both engines it is fantastic. I think they push each other which is why the competition for me is great. Because they really push each other now and it just creates this momentum between both engines that I feel is fantastic, and it's nice. Its always great to have competition and be able to learn from each other and push the language even more than they would by themselves.
I love the fact that Adobe has that infographic that show's how they will be supporting CF all the way up to 2040 or something like that. It gives confidence in corporations that have investments in ColdFusion that Adobe, first of all, is not going anywhere. They're committed to it. And that I really appreciate and I really like.
And they're even expanding. From their API management tools and the analytics and stats. I really love the API management tooling that they have developed.
Michael Smith: So I know some people in the past have wondered whether ColdFusion is dying. So I have a question opposite to that which is, what would it take to make ColdFusion even more alive this year?
Luis Majano: I think that first of all corporations need to evolve. They can not be stuck in the CF 8, CF 9 days. They have to invest in themselves. So that's the first big thing is that these corporations are doing tremendous amounts of money with ColdFusion, they need to evolve. They cannot stay where they are. That's a plus.
And then the second thing is that will promote developers to come and work for them because nobody is going to come work for procedural programming. I mean nobody. No wonder nobody wants to go do ColdFusion because they don't want to be working with procedural code. So if corporations don't do this ColdFusion will not be alive anymore. So the corporations really need to modernize. That's the first thing.
And then once that is in place and developers start getting into these workplaces is that people need to start building apps. You know, that's what made PHP what it is. It might not be all quality, but the community and ecosystem just grew because people were really investing in building applications. And sometimes I feel ColdFusion developers, and mostly because of that inherent nature, they live in procedural land, they need to start creating apps. You know that's why we created ContentBox and all these Boxes to really promote the language.
Most of the times you cannot go to your buddies and say “Hey, look at my closure.” Or “look at my component. Look at how awesome it is.” No most of them are going to say “Hey. Look at ContentBox” right? I do in fly updating, it's a content store, and it has a restful API and all this. That's what catches the attention of folks.
So those are, to me, the two major things to keep ColdFusion moving forward.
Michael Smith: Cool. So what are you looking forward to at the Into the Box conference?
Luis Majano: Oh man, I'm a sucker for mariachi's so I am excited to have a new band this year with many, many little surprises. I won't divulge all of them, but it's going to be big. So I'm looking forward to the Happy Box Event. But most of it I'm really just looking forward to meeting with all these folks and networking with people. New folks. I think that right now we surpassed already the attendance from the previous two years so I'm really excited about that and still about 18 days to go. So there's still a lot of time for people to still register.
So I'm excited to just meet and mingle, and also get feedback on all the stuff that we're doing and where we want to take a lot of our tooling.
Michael Smith: Yeah I often find at conferences I get as much out of the hallway track as I do from going to the sessions.
Luis Majano: Yeah. Definitely. SO we have a huge section for networking this year right by the sponsors. I'm just happy to be able to mingle with folks.
Michael Smith: Great. Well if folks wanted to find out more about you, how would they reach you?
Luis Majano: You can go to intothebox.org or ortussolutions.com. And I still have my blog, but I haven't blogged in so many years at this point, but if you can go to Luismajano.com you can find me there. But most of the time we're doing our writing and blog on Ortus.
Michael Smith: Great. Well thanks so much for being with us today Luis. Its been great talking with you.
Luis Majano: Yes. You too Michael, and I look forward to seeing you soon.
Michael Smith: Okay.