You can listen to the podcast and read the show notes here
Michael: Welcome back to the show. I'm here with Gert Franz, astrophysicist and expert on LUCEE CFML, in face he's the evangelist for it. When I said astrophysicist I think he did that like 25 years ago so we won't ask him any difficult questions about the galaxies, but we will be asking him a lot of questions about debugging templates and Jedi tricks he has for debugging and error handling and also look at how you could write your own debugging templates and why you might want to do that.
Also we're asking him a bit about cf.Objective where he's going to be talking about debugging templates and also ask a little bit about LUCEE, and Railo, and all kinds of other ColdFusion related things.
So welcome Gert.
Gert: Yes. Welcome Michael. Long time no see, I guess it's about three, four weeks ago right when we had met?
Michael: Yes. I think there was some Texan barbecue being served and I think it was a mariachi band at the Into The Box conference.
Gert: Exactly. And regarding astrophysicist, I studied astrophysics that's true, and I can tell you once I visited a client who has a lot to do with astrophysics and I was presenting Railo back in the days, and I remember at the end of the talk I got nervous, because I was thinking something like, “Okay, when they gonna ask me questions, they're gonna kill me with the questions.” Like, “how fast are the electrons moving when I'm doing a CF output?” Or something like that, so I did my talk, was sweating, and then afterwards people were asking me, raising a question, I got nervous like crazy. They were saying, “Do we need to install ColdFusion to run Railo?” Like, oh god, really?
So that was really funny, and that kind of was my extended thing that I got in touch with astrophysics more or less. So, I just have my telescope at home, well which I sold recently, but I'm gonna get a new one. That's my extent of doing astrophysics lately. [crosstalk 00:02:18]
Michael: Yeah I just have an imagination that you could get LUCEE running on one of those raspberry pie computers, and have it control your telescope.
Gert: Well, that is true.
Michael: ColdFusion application for taking photos and all that stuff.
Gert: Yeah, I'm pretty sure that that is possible, especially when I see what Brett Wood is always doing with his raspberry pie, I think that is a great thing. And I'm pretty sure that can be done, but as I told you before I'm very busy doing nothing, and therefore have no time for that. No, we're doing tons of other things. At Rasia where I work, we have certain products in the pipeline coming up, all having to do with performance. And, if you are at cf.Objective and you want to learn anything those about those products, just come and visit me or come and ask me and I'll be there to show the latest and greatest of what we're doing.
Michael: Well, I know you're a performance expert because we've chatted for an hour or two in Houston about how to optimize stuff, so I'm looking forward to that, that sounds really interesting. I never did astrophysics, but I certainly did a lot of mathematics and I did bump into Stephen Hawking a few times 'cause he was in the next door college to mine, and would trundle across.
Gert: That is really … That would have been one of my dreams. That actually was my original dream when I came to … from Romania, when I came in '82 to Germany, saw the space shuttles flying or launching from Cape Canaveral. And I told my dad I'm gonna work for NASA once, and he say, “Yeah, yeah that's fine go ahead, do your thing.”
No really, I completely aligned my life to work for NASA later on in my life, so what I did is I had math and physics in my high school as my main subjects, then I went to university Munich and [inaudible 00:04:29] in Germany to study astrophysics. And afterwards I wanted to really go to maybe somewhere in Boston or in Houston or somewhere in Florida and work for NASA.
Anyway, I was starting programming in the meantime, and I made pretty good, pretty decent amount of money, so I said, “Oh screw astrophysics, I'm never going to stand a chance anyway.” So I started programming, and over the longer time it brought me to ColdFusion and to Railo and to LUCEE and then 2011 when we're at a CF conference in Washington, Curiosity landed on Mars, and we knew that people were downloading from NASA, they were downloading the software, so we though that would be great 'cause those guys would use it, because we knew they were using ColdFusion a lot. So anyway Curiosity landed and two or three days there was a press release from Amazon saying they were only able to manage those four million sessions simultaneously with Amazon web services and Railo [inaudible 00:05:33].
Michael: Wow.
Gert: Was that right? Okay well anyway, I get involved with the guys over there, so they invited me to give a lecture and some important other stuff, came home picked up the phone, and called my dad and said, “Hey dad, I'm working for NASA.” It was about 30 years later, but it worked in the end. So that was kind of my closing the loop after 30 years.
Michael: Wow.
Gert: So I'm all into … since day one, with the [inaudible 00:06:07], or with Railo back then, we were all into performance. Everything has to be performed and one of the most important things that I was using since day one was debugging information. And for a long time I really wanted to do a talk about what to do regarding debugging and how to use it and stuff like that. So that's why the talk came alive, or actually will come alive.
Michael: So what exactly is a debugging template?
Gert: Well, a debugging template. Let me put it this way, when you execute a page, or you can call it a request, LUCEE does, or ColdFusion do a lot of things in the background and collect information along the way as long as you have debugging turned on. Turning on debugging is pretty simple, just go to the app and tick a box.
Now in LUCEE there's a couple of differences. What you have is debugging turned on, allows you to collect the information. It doesn't output anything. For the output of that information you need a so-called debugging template. And this debugging template is something that formats the information that LUCEE collects in a way that you can better read it, and we're all maybe familiar with a ColdFusion debugging template. And so I looked up the information a lot in the past 10, 12, 13 years and I even added a couple of things that had to end up in the debugging information. So it is always good when you're sitting close to the source and you're part of the source and you can define what ends up in the debugging information.
So writing an engine like LUCEE or Railo back then, or being in the team that writes it, allows you to have certain influence on the things that end up in there as well. And a lot of people are under-estimating the information that these … that debugging can give you.
so to get back to the question that you have, what is a debugging template? A debugging template is just the HTML and CSS that formats that structure that you received from LUCEE, or from ColdFusion, in a readable format into a web page. That's a so-called debugging template. In ColdFusion there are, I guess, two or three. There was one that was sending it to I suppose the flex [cluster 00:08:45] or some kind of flex client for Ajax debugging. And there is another one that is called Classic as far as I remember which is just adding it to the bottom of each page and there is, I guess, another one which is using comment where you can have all the information in an HTML comment inside your HTML source.
So that is more or less a debugging template.
Michael: Okay, so it's what gets fired when the CF error [crosstalk 00:09:20]
Gert: No, not the CF error, that is the error template. The error template is a template that is called when you have an On error or something, or CF error. That is the error template. You can set that up. But the debugging template is the stuff that is below your page, where it says these amounts of queries, these …
Michael: Oh okay.
Gert: … pages and how long did they take to execute.
Michael: Yeah, the thing that you turn on for certain IP addresses or however you control it.
Gert: Yes, exactly.
Michael: Got it. Thanks for clarifying that.
Gert: That's debugging and debugging template, right?
It is [crosstalk 00:09:56] step-by-step debugger, it is just a host debugging kind of …
Okay, go ahead.
Michael: Right. So why would someone want to turn that on and tweak around with it?
Gert: To be plain and honest, I have it on all the time, even on production sites. Now people are gonna say, “Are you crazy? You're disclosing information there,” and what have you. Well first of all you can limit those things to IP addresses and second of all, at least in LUCEE, the amount of time it takes to process the debugging information and output it, is next to zero. It still has, let's say one or two percent of overhead, but the information that you have from those debugging templates is really invaluable.
I remember the first days when we were programming Railo back in 2003. We had our first version of Railo running at the [inaudible 00:10:51] was measuring the performance between … what was it … not on [Lair 00:10:57] … who bought it from actual Lair?
Michael: Macromedia.
Gert: Macromedia, yes. From Macromedia, ColdFusion versus Railo back then, was about six to one, so ColdFusion was about six times slower back then than it was … They have improved a lot so no worries. And maybe it's our fault as well that they had to improve, but that's fine.
And I remember that it was six times slower, and the way I was measuring that was with turning on debugging. What I hadn't taken into account is without the debugging in ColdFusion, at least back in the days, is adding about, in that case, 50%, 60% overhead, so when I turned on … off debugging and just did a tick count thing, it was only three to four times faster, which was dissatisfying but still it was good enough to put a … to launch it into a new product.
So there is a difference if you do that in ColdFusion versus LUCEE, turning on debugging or not. If you have some kind of code blocks application which has thousands and thousands of methods, [calls 00:12:06] and what have you, the debugging really might slow down the request execution a lot. In LUCEE not so much, but in general, you shouldn't. But I tend to leave it on all the time. It's a … Why would you want to use it? Pretty clear, it gives you all the information about what happens in the request. Not all of the information but very important information about what happens in a request. Like, for instance, what queries have been used or what files have been used, which files have been slow, and stuff like that.
Michael: So ti can help you if you're trying to figure out some problem with your code, why it's running slow or why it's not working right?
Gert: Yes. Well it is not … Let me put it this way, it is not really pinpointing to the exact location, well sometimes is does if your variances have a very slow query execution, then you know that this is the problem that you should look at and so if you have a 10 second execution and 9.5 seconds is one single query, then you know that that is an issue, and you can easily see that from the debugging information.
But if it's, for instance, one file, you will just see that that file is the slow one. If the title is huge and massive, you of course have to go into details there and just [inaudible 00:13:25] take count [inaudible 00:13:27] introspect that, or you do something like the … one of the products that is coming up from us or [inaudible 00:13:34] has something like the request introspections or whatever it's called.
Michael: Yeah, all right. So there are some pre-built ones that come with Adobe ColdFusion, or come with LUCEE CFML.
Gert: Yeah.
Michael: Why the heck would you want to write your own?
Gert: Well, the thing is that when you're writing a language, programming language, you of course have to find a middle ground for displaying information which would satisfy everyone, right? So this is how I would display the queries, this is how I would display the files, and stuff like that. But this is, of course, just the common ground.
There is so much more information on the debugging struct that you get … that LUCEE returns to you, in our case, that you can use that information to do all kinds of other things. Like, for instance, just a simple thing, warn me if my session is larger than 50 kilobytes or something like that. Or give me the hierarchy of the execution of the template so that you know this template has been called by that one, and that execution took so and so much. That information is in the debugging template, in the debugging struct in the debugging information, but nobody outputs it.
Or how many of my query columns have been used, in fact. Or what the dumps are that I'm using in my code because you can tell LUCEE to do … dump the results into the debugging template and not display them on the page in the first place. So stuff like that.
Now …
Michael: Sounds handy to be able to do that.
Gert: Yes, it is. And I … yep, go ahead.
Michael: But it … is it really … do you have to be a genius-level ColdFusion developer to write these things or is it standard ColdFusion code or …?
Gert: Absolutely, we wrote it very, very difficult … we made it very, very difficult to handle because we want to sell our consulting services. No, not at all. It is general, plain CFML, so writing a debugging template is just working on a CFC. A CFC has a [inaudible 00:15:49] method and a body, and in the body you define the arguments that are coming from your definition of your debugging template. So when you go to the admin and select the template you want to use, it allows you to pass in some arguments. And these arguments will come into the CFC, then you have an output method and this output method receives the whole struct containing that information. What you do in that output method is completely up to you.
So it is a simple struct containing several keys containing maybe queries, arrays and stuff like that. It's pretty simple what you can do at first, just dump whatever there is and then have a look and come up with some ideas on how to interpret that data.
I have written two or three debugging templates in the past and so I can tell you about the history of these debugging templates. I wrote a debugging template called Debugging to Console. Debugging to Console was just writing the debugging into the background somewhere and then you have a debugging console where you could have a look at all the debugging entries from everywhere, but the actual page that you were calling, didn't have any debugging output below. [inaudible 00:17:10]
Now this has made its way, now, into LUCEE and LUCEE has this debugging console in the administrator. I will show that in the talk so that people can relate to that, that they understand what's going on there.
Michael: So one thing I'm wondering is, what happens if you have a bug in your debugging template code?
Gert: You just get an error saying okay something like, okay that file is not defined. Then the error template is called instead of the debugging template. But just below, because the debugging template is something that will be called separately from your request. So your request will run regularly, normally, and then below you will have your error template displaying the error that you have, so it's not really a big deal.
Michael: Okay, so it's not like when you have an error in an error-handling template?
Gert: Or if you have an error in an event gateway or an Ajax call, something which you have no idea whether or it's not happened.
Michael: Right. Okay so it's pretty easy to write these yourself
Gert: Yes very.
Michael: Or to take one that comes with the language and just tweak around with it to make it do what you want.
Gert: Yeah. I can tell you in the last 15 years, I've seen one single person that has written its own debugging template, besides the LUCEE core developers.
Michael: Well, maybe there's an opportunity here for people to get better info.
Gert: Yeah, perhaps that is an opportunity, especially now with skills or the techniques that are available there with jQuery doing stuff there in the background and stuff. Decorating your data, your debugging data with additional data that you can request from the application, is not really that hard. So you can just simply have an additional file that you call there which gives you additional information to whatever you want to see there.
But just people are not using it. People are not used to use these debugging templates to fix their issues, to understand better what kind of code they're writing, what mistakes they do.
Michael: Right. So are you gonna actually in your talk at cf.Objective, are you gonna show people how to do this themselves?
Gert: Well, I hope so. So what I'm going to do is I'm going to show them how to understand the data, how to write such a CFC, what happens once this CFC's done and how it interacts with LUCEE. And what I can give them is a really very great, shiny debugging template that I have written which is my favorite debugging template as of lately, and that helps me really a lot focus exactly on what I need. One of the things there is … if you have, for instance, a ColdFusion … ColdBox application and you want to focus on say one single file and all the queries and everything, and everything that's descending from there, it will be buried under those thousands of calls and thousands of queries, et cetera, and I wrote a debugging template that allows me to say, “I want to debug this one, and all the descendants of this one.” And only see that information which is related to that, nothing else.
Michael: Oh, so instead of getting pages and pages of debugging info you get with a default template, you can narrow it down just to the stuff you interested in.
Gert: Yeah so whatever … exactly.
So that is what I wrote about a half a year ago, and I'm still using it and I love it. And I will spread it with the world and they can use it, that's fine.
Michael: Fabulous.
So how is LUCEE error handling different from Adobe ColdFusion?
Gert: Well, I wouldn't say LUCEE error handling or LUCEE debugging … LUCEE debugging is different because LUCEE error handling is the same as it works in ColdFusion. I guess this comes from the misunderstanding that we had at the beginning that it is not a LUCEE error template, it is a LUCEE debugging template. So I suppose this question was something that was related to that but, there are differences in LUCEE debugging templates, versus ColdFusion debugging templates as well.
ColdFusion, as maybe some people know, has one administrator per server where ColdFusion runs, per instance. And that means you have … you can turn on your debugging template for all of your sites or not. Whereas in ColdFusion … in LUCEE, you will have a LUCEE administrator for every of your single individual websites that are in the same instance. And you can have all different kinds of debugging templates turned on from one side and turned off for the other side. And what you can do as well is within the same site, you can say this IP address gets that debugging template, and this IP address gets that debugging template.
So you can even do, in a weird scenario, you could even do something like Google Analytics in your debugging template if you so wish. That would be added to every single page. I mean this is stupid, but just to make a case for it. So you could definitely have different debugging templates for every single individual IP address.
Yeah, so that's what the bigger difference there is.
Michael: So it sounds like you do a lot of debugging. Can you tell us some Jedi debugger tips?
Gert: Well, some Jedi debugger tips. I know that I actually had a big issue that I have introduced in a debugging template that we were able to … that you were executing on the … within Railo back in the days. So what I did back then, I wrote a … When you output the queries in the debugging template, I had a button there which says Play, and you can just replay that SQL statement just to get the content of that query that was called with this SQL statement. And that call was actually a call of the server added … and passing in the form scope the SQL statement. And of course, Pete Freitag came a few months later saying, “Hey guys, you have an issue there with SQL statements, I could pass on a drop database in there.” And it was just wide open. So you have to be very careful with that.
But debugging Jedi tricks. So for me, what is really very important is you can turn on or off the SQL server usage or the SQL … sorry, not SQL server, SQL usage. That is a tick box in the administrator and the tick box in the administrator enables LUCEE to survey what columns of your queries you are actually using. So if you're pulling SELECT* from something but you're only using two columns, it will complain and say, “Hey listen, you're only using 3% of your columns. Wouldn't you narrow that down?” That is that one tick box.
And the other tick box which is a very useful tick box in development, is the implicit variable access. The implicit variable access is something like the … what was it called, [inaudible 00:24:56] Camden's tool, the one that introspects whether you have localized all your variables? A variscope checker. Yes. It was called variscope checker where you were looking whether in your methods of your CFCs, you had [inaudible 00:25:13] with every of your variables that you didn't intend to end up in the variable scope of components. And it is like a variscope checker on steroids.
LUCEE will check every single access to a variable and see whether it has to jump through many hoops to get that variable, because in CFML there is this stupid invention that you can call a variable, or you can invoke a variable but just using the name without a scope. And if necessary, CFML, LUCEE or ColdFusion will hunt down the variable somewhere in one of the scopes. That is very bad technique, by the way. And if you wanna get rid of those, what you can do is you can just check this box and it will tell you all the variables that you have accessed without explicitly scoping them. Except for the local and the variable scope. Those two are the only scopes that you shouldn't scope in the first place. This is working all the time. So it is really literally, at that point in LUCEE where the variables are accessed so it will not fail.
Now the thing is just this costs you 30%, give or take, 30% of performances so only enable that in development and nowhere else. That is a very nice feature to use if you wanna speed up your code as well. There are tons of other things but I don't want to give everything away because nobody's gonna show up in the session afterwards.
Michael: Yeah, and I'm not just talking about what you're gonna talk about in your session, but also just things you do when you're debugging code.
Gert: Well, when I debug code, the first thing that I will do, and that is a take away that I do from every single … from that talk that I did about performance, is that if I have a code that I'm analyzing for performance or for bugs, I write it from TAC script or from [tinker 00:27:18] script to TAC. Now you might go, “Why would you want to do that?” Well very simple. It is not for performance reasons or something, it is just for me to understand the code. If I rewrite it and it still words, maybe I understood the code.
Michael: Oh.
Gert: Mostly I write from TAC to script because mostly people are converting from TAC to script, but that is the first thing that I do and that gives me a feeling for the code and I understand what the code does. And while writing that, my head always goes like, “I would have written this a different way,” or “this is much more [inaudible 00:27:56]” So while I'm rewriting it I already think about alternatives and how to improve the code. So that is a very … it's just like the code monkey. I guess you know the code monkey, right? Where you tell …
Michael: No tell me … tell us about the code monkey.
Gert: Well that is something, first time I heard about this was from Mark Drew and quite simply I learned about it from 9GAG, I don't know if you know 9GAG, but it's a very famous app on iPhone or iPad, just funny stuff, and it's a lot with gaming and computing and programming. And the code monkey is the monkey that you sit next to your laptop or computer and if you're stuck with a problem, you try to verbally tell that problem to the code monkey, because I'm pretty sure that it has happened to you very often, that you're stuck in a problem and then you explain the problem to somebody else. And as soon as you've explained it you go, “Oh, I know how to fix it.” I'm sure that has happened to you, it has happened to me a lot.
Michael: Oh yeah.
Gert: The same thing is here with the code monkey. The code monkey forces you to verbalize the problem that you have and by verbalizing you're transferring it, sort of like me converting from TAC to script. Transferring it into normal words and that helps you understand the problems and then you know better how to fix it.
Michael: Right. I've done that, phone up a friend and explain what you're doing and halfway through the phone call they don't solve it, but you figure, “Oh I did this stupid thing.”
Gert: So you can tell your friend that he was your code monkey.
Michael: That is a great thing. I almost want a little cuddly monkey to stick next to my computer so I talk to.
Gert: Yeah, well Mark has his dogs, we have our dog and a cat as well, so we can explain to our dogs what issues we have. Hi, to JR. JR is Mark Drew's first dog.
Michael: So yeah, talk to your pets as well. But anything that helps you go through the code can do that. One of the things I used to do when debugging is I'd make a copy of the code or maybe the whole app depending if I didn't quite know where the bug was and then I'd just start ruthlessly hacking pieces out of the code until I couldn't get the bug to occur and the last piece of code I cut out was related to the bug.
Gert: Yeah. And, oh, one other thing that comes to mind regarding the debugging tricks, what I do as well is just ready, as you just said, I cut out pieces from the code until the error doesn't happen any more. Just narrowing down the problem until it doesn't happen any more. Just like if you're using an image on several inner joins in your SQL statement and you don't get any data so you just do a left join, left join onto … or you just delete that until you see data finally, and then you know, okay, there is the issue.
Michael: Yeah, I think debugging SQL is a whole other skillset.
Gert: Right.
Michael: It's really not quite as friendly a language as ColdFusion to be honest.
Gert: That is true but I'm a very huge fan of SQL and a very huge fan of databases, that was the thing I did before I came to ColdFusion or to CFL. First time I saw it I thought, “Oh god, what is this?”
Michael: Well, and I think with SQL in particular, just being really anal about how you format it and even indenting the SQL so you can see does everything match up the way you thought it matched up?
Gert: Yes that is true. I work a lot with Teradata, and the Teradata SQL Explorer is really [inaudible 00:32:05] really sucks. Sorry, excuse the language but … it really, I don't like it, even though Teradata is a great database and everything. But sometimes really debugging a SQL statement in Teradata … [inaudible 00:32:21] here over there [crosstalk 00:32:23]
Oh yeah, that was from Teradata. Yeah but still, I really love writing database queries and opt-in my stuff there. Not a big of ORM, hence …
Michael: Right. I actually do think that there's a different skillset involved in being able to debug code versus being able to write code and some people are really good at debugging and they're not so good at coding, and some vice versa.
Gert: Yeah, what people are always telling me, and about four or five hundred years ago if we were doing programming back then, I would have been burned as being a wizard or a bad wizard because of that. Because sometimes if people are telling me about an issue, they explain to me the issue and I don't know how this works, but after a certain amount of time, when it comes close to the issue, my brain snaps and it just goes, “Oh, wait. Please go back and explain that to me.” I don't know how that works but it just works, and then he goes into detail about that particular issue and then he tells me that again and then again the same things happens, my brain goes (clap) and then, “There is their issue, that's the problem.” I don't know how that works but I just sometimes notice that whatever somebody tells me, I try to follow and as soon as my brain can't follow any more, I know that there might be an issue. It's not a …
Michael: It's just your intuition speaking to you.
Gert: Yeah. That's my female side I suppose.
Michael: Yes, there you go.
So yeah maybe a few hundred years ago you might have been burnt for the stake because you were getting debugging info from your intuition.
Gert: Exactly.
Michael: But now I think we can openly admit that sometimes we get intuitive nudges. And I think everyone listening has had the experience that you're trying to debug some code and you go take a walk, or you sleep on it, or you take a shower and suddenly you're like, “Oh yeah, I know where that problem is.”
Gert: Yeah, that is true and especially when it is other people's code. That is sometimes because you have to then think as they would think and sometimes …
Michael: Sounds painful.
Gert: Yeah. But I love doing it. There is nothing more pleasing than complaining about other people's code.
Michael: Yeah. So let's switch to a few other topics here. You mentioned earlier that you were born in Romania, you lived in Germany and now you're in Switzerland and you just got married I think you mentioned. So congratulations.
Gert: Yeah, I got married, yeah thank-you, I got married last year to a Swiss girl, actually my boss.
Michael: Fabulous, and you're gonna become Swiss I hear, I think?
Gert: Yeah, next year I'm gonna become a Swiss. I was just lazy to apply for it, but I've moved 29 times in my life. So quite a lot.
Michael: Wow.
Gert: And the longest place that I have stayed is actually where I am right now, so I'm in Switzerland now for 20 years and I [crosstalk 00:35:34]
Michael: Wow.
Gert: I've moved a couple of times here in Switzerland as well, but in this place where I am right now, I'm here for 12 years already.
Michael: And Switzerland's a very interesting …
Gert: [crosstalk 00:35:41]
Michael: … country because it's very federal model, the Cantons and the cities and the Federal Government all share the money and the power, which is pretty unique in the world.
Gert: I wish they would.
Michael: You wish they would?
Gert: Yeah I wish they would share the money. Well the power, yes they do because every second week we go … have election week or election day and you have certain petitions that people can file, like you need to have a hundred thousand signatures to file for a certain petition, and then you can decide about certain things to happen or not to happen. So you have … that's why it's called the Direct Democracy. And I really like that. I really like that a lot.
The only thing that I don't like is that sometimes the explanations on what things, how laws should be or what [inaudible 00:36:33] signing upon, are very complicated. And there is one small flaw in the whole thing. You get a booklet, a small booklet, and that booklet explains to you what you're deciding upon. At the end it says the government is, how do you say it, the government is proposing you to do this, which is bad because a lot of people are going, “Oh this is way too complicated. What does the government say? Okay, let's do that.” So that is wrong, because they shouldn't say that. They should just much more simple explain to you what this is all about.
Michael: Maybe the whole democracy process needs a debugging template so you can understand what the proposal is.
Gert: Yeah and I'm sure … I'm trying to do something about that. We have some other ideas there. Yeah, I think Switzerland's really a very great country. It is unfortunately one of the most expensive countries in the world but hey, everywhere I go it's cheaper. But still sometimes it's really crazy how much you're paying for a beer or something. It's $12. Crazy.
Michael: You just have to make your own.
Gert: Well we're not in America where everyone is home-brewing.
Michael: Yeah, I'm sure that Brad has probably got a raspberry pie CFML project that would totally control the beer production process.
Gert: That is true. But anyway, that's a whole different topic regarding Switzerland and all the [inaudible 00:38:11]. I'm happy to talk about all of those things but I think we need more than 10, 15 minutes.
Michael: No, just curious. No we've only got a few minutes left and we want to talk about LUCEE and Railo a bit. I am curious how many languages you speak 'cause you're speaking excellent English, but you must have learned Romanian and German. How many other languages do you speak?
Gert: Well I speak I guess six or seven languages. The thing is Mark Drew has always a very nice quote about me. “You know, your English is really almost impeccable. I I know you're doing something wrong. I have no idea what but you're doing something wrong.” And that's funny. I would have loved to have the perfect English because the colloquialisms are missing sometimes, but I would have loved to have the perfect English, but hey, people need to know that I'm not from the States. They excuse my variable names, right?
Michael: Oh yes, the long German variable names.
Gert: Yeah long German variable names with umlaut and everything.
Yeah, nonetheless, I speak a lot of German mostly [crosstalk 00:39:19]
Michael: Do you think that helps you in your programming, 'cause you mentioned earlier you had to get yourself in the head of the other programmer to understand that code. Do you think actually speaking more different languages …
Gert: I don't think so. Maybe the comments. Just recently I talked to a guy in Brazil and he knew absolutely no English at all. He was talking to me … he was chatting to me over Skype with Google Translate and it was hilarious to sometimes read something which I really couldn't make sense of it at all. And I had to ask him twice or three times, what do you mean? And then he used a different translator and then it made sense. It was very funny.
But I don't think that knowing many languages makes it easier, but what it does, it makes you more tolerant, especially if you're traveling a lot. If you're staying in the same country all the time, you'll have a very narrow-minded way of thinking about things. But the more you go to different countries, the more you go, “Oh, okay, here it is. Like that, that's fine.” Here they're using miles. So what? It's a little longer than a kilometer, who cares? The ant doesn't care whether it is a mile or a kilometer.
So you get a lot more tolerant regarding national habits and you don't take them very seriously.
Michael: Well I think that's important when working with other developers to not take things too personally. So bearing that in mind, what did you lean from the Railo project? Railo [crosstalk 00:40:54]
Gert: What did I learn from the Railo project? Yeah, what it learnt me is that life is not endless and that we should live our life while we can because getting angry about things, especially in the end, is not worth it. We try to move things, we try to bring things to the world and try to improve things for the CFML community since day one when I started with the Railo project and in the end it was no fun any more. So we had to do some changes there. And we did, and since then I'm really happy that I'm free and we can care again about the CFML community and be the thing, or be as strong as we were before and as helpful as we were before.
It was really a very nice and very long journey. I still love Railo. There are no bad feelings regards anything. Maybe a couple of situations could have been different but I won't go into very many details there because you leave that behind in your head as well. You try to make things better and you try to improve for the future so that you don't do the same mistakes again. And it gave me a lot.
Michael: So what's your … That sounds a good thing, to leave things in the past behind. How do you manage to do that, 'cause I'm sure some people listening would love to be able to just let go of some stuff in their past, and their programming career?
Gert: That's a broad question really. A bold question. The thing is, what is important is, there is one thing. I told that to my kids as well. There is nobody better in the world than you. You know why? Because you won't get anyone else. It's just you. So finally admit it that you're the best person in the world. You are because you can't be somebody else and if something's not the way you want it to be, you have to change your attitude towards it, or change yourself. And that's what I've done for the last two or three years. I've tried to live my life more … just like the Ferris Bueller quote, I say, “Life's so fast. If you're not stopping to look around every now and then, you might miss it.” And that is true. We are here for a brief time and we should just give it our best because how can we spread happiness if we're not happy.
So that's what I try to do and being a LUCEE developer or being a LUCEE evangelist makes me happy. And I try to make other people, programmers' life happier.
Michael: I think being happy is a good way to get better work done, better code written, get on better with other people and also making the conscious decisions to be happy, actually does make me happier. It's weird but seems to work.
Gert: Yeah, it is true.
Michael: So, if folks listening are thinking how could they contribute to LUCEE, CFML, how could they help out in some way, what could they do?
Gert: Well, it is very easy to complain about [inaudible 00:44:11] things like for instance, “Hey the documentation for this is missing,” or “Why wouldn't you document blah,” or whatever. We have invested really loads and loads of time and money into this and of course, we have forgotten things and we haven't documented things so that you can come to us and ask us for consulting. No, the thing is that sometimes we just didn't have time or we just forgot to do it.
So the best way to help the LUCEE project is to get involved, to go to [inaudible 00:44:40].lucee.org, start a discussion, become a supporter of LUCEE. Just go to the lucee.org website and sign up as a supporter. It's just nine bucks a month and it helps the LUCEE project as well. The LUCEE project is just there to fund the LUCEE developer, nothing else. No commercial interests. It's just a non-for-profit organization and the LUCEE development in the spreading of the name is the only thing that this is for.
If you have a larger company, why not become a member then you can have influence out of where LUCEE is going to head in the next few years. Are we going to create a headless LUCEE version? Are we gonna create a server-less LUCEE version? Is it going to run on … I don't know, an iPhone or whatever? Well, that's up to you then if you become a member and decide to become part of the management deciding where the direction of LUCEE's gonna go.
My company Rasia, where I'm working at, is one of the founding members of LUCEE and I'm really happy to give loads of my time to help bring LUCEE forward as well. So why don't you guys do it as well? Because if the thing that you love, the thing that you work with every day and why not contribute something back instead of complaining? Complaining is good, maybe it moves things, but the better thing is just do it yourself, fix it immediately.
Michael: Yeah and because LUCEE's opensource, you can have a chance to do that fixing if you want to.
Gert: Yeah.
Michael: Or help debug it. Maybe you can't fix it yourself but you can like, well here are the different cases where this problem occurs and that helps someone else who is trying to fix it, narrow it down a lot quicker.
Gert: Exactly.
Michael: So great suggestion. So should people listening go to ColdFusion conferences, and why?
Gert: Well, the thing is, I know sometimes the employers are deciding over the heads of people whether or not to go to conferences and very many times we don't have the chance to go to conferences. But what is really invaluable at conferences, you get to meet other people. You get to meet other mindsets. You get to meet other ways, how people are solving issues. You get to meet the developers and the core people behind the languages. You can ask them stuff. You can leave an impression. You can do very much … you can interact with these guys. They are really very, very bright guys at these conferences.
Cf.Objective especially has been always the conference where the guys in the audience could have been the guys on stage and vice versa, because it is a very high level conference and I always love going there and talking … having the privilege to talk. I had the privilege to give the keynote a few times and it was really always very inspiring and I love that conference, especially working with the Steven [inaudible 00:47:48], it's a pleasure as always. And going to conferences really gives you a feeling of, “Okay I'm part of something. I'm part of the community. And I'm not just somebody in a [inaudible 00:48:00], in a small box programming whatever my employer tells me to do.” It is being part of something, part of something bigger. That's what conferences are all about.
Michael: We're going to be done in a few minutes. So why are you proud to use Cold Fusion?
Gert: I'm proud to use Cold Fusion. Well, Cold Fusion, I don't use that much Cold Fusion, I mostly use LUCY.
Why am I proud, well maybe because I was one of the key members that allowed the language to survive or allowed the language to exist. I had some influence on the development of the language as well. And obviously just like you having your baby, see how your baby evolves and teach it some new skills, and you're proud of that baby.
Me using LUCY all day as a day job makes me really proud. There is something about the language I don't like, I maybe help change it. And you don't always have the opportunity to do that with languages because your influence as a programmer might be very small.
But being at the core gives me a little bit of influence, and backing the project as well gives me a little bit of it influence. And it makes me proud to see that other people are using it as well. That we are allowing an industry to survive and for it to flourish even still.
We've seen the number of Cold Fusion users going down over the last ten, fifteen years. But, over the last one year maybe, it is stagnating and sometimes I think that it is going back up again, which is great. And I think that it is really a very good time to start using Cold Fusion or LUCY again because lots of companies are out there that have Cold Fusion applications running. Maybe old applications, maybe new ones.
And one thing that they search really the most is Cold Fusion developers. So, I'm pretty sure you're making a lot better money than a PhD developer if you're a Cold Fusion developer with some skills. And that maybe could be a very good argument to try to learn Cold Fusion or CFML as fast as you can and use it as your pet project if you like, sir.
Michael: So, what would it take to make Cold Fusion even more alive, Gert? This year.
Gert: This year, well talk about it, that is important. Talk about it, blog about it. Use it for applications. Go on CF Alive and talk to Michaela Light and tell it how great it is. We have loads of people saying how bad it is and how old fashioned and old code and whatever. Tell them it's not true and why it's not true. Because the ones that are using it heavily know that it is not true, and that we are trying to keep the language as modern as possible and improve it. And make it as fast as possible, and as competitive as possible. So, it's mostly really, again talk about it and chatter about it and yeah do these video recordings of Michael.
Michael: Well, I'd love anyone listening who wants to be interviewed, drop me an email, [email protected]. I also just put up a thing where you can leave me a voice message if you want to leave comments or questions on the TeraTech podcast page. For CF Live.
Gert: Okay
Michael: Happy to share feedback in future episodes from listeners. Thanks so much for being with us Gert. If people want to reach you, how would they find you?
Gert: They can just use my email address [email protected] R-A-I-S-I, dammit I've never spelled it in.
Michael: We'll put it in the show notes.
Gert: Rasia.ch. I've never had to spell it before like that. Anyway, that's where you can reach me or Gert_Rasia my Twitter handle or Gert.Franz, my Skype handle. Just drop me a note and I'll be happy to help. And Michael, I guess we meet again in six weeks in Washington.
Michael: Six weeks, yes CF Objective in Washington DC For the first time this year instead of Minneapolis. It's going to be in the east coast. A lot easier for people to get to, I think.
Gert: Yeah
Michael: I was speaking to Steven Hauer and he said that was one of the reasons they moved it. ‘Cause, getting to Minneapolis is not the easiest place to get too.
Gert: That is true. That is true
Michael: And there are one or two more tourist attractions in Washington DC.
Gert: And one that has become a lesser attraction. Okay, forget it. Yes, all this fun. I love going to Washington, really one of the greatest places in the states. I really love being back there.
Michael: Great, well Look forward to seeing you again and thanks so much for being on the podcast.
Gert: Yes, thank you very much. Michael, see you soon and take care bye-bye.
