You can listen to the podcast and read the show notes here.
Michael: Welcome back to the show. I'm here with Guust Nieuwenhuis. I hope I'm saying name right there. It sounds pretty Belgium to me. And we're going to be talking about continuous integration in ColdFusion with a bit bucket pipelines. And Guust is doing a talk at C.F. camp on plumbing with bit bucket pipelines. So, we're going to look at what those are, and why all ColdFusion developers might want to have a look at those. And why doing continuous integration in continuous development are a good thing. What he likes about the bit bucket repository. And we'll also look at how integrates with Docker containers, and how you can use it on your team. So welcome Guust.
Guust: Thank you, thank you for having me.
Michael: And if you don't know Guust, he has been a ColdFusion developer for a while. He's a full stack developer and he's currently developing his own part product Pedrilo [01:01] which is a Lucian solution for music. And that's one of his hobbies he plays the double bass so. And the drums, so very talented man.
Guust: thank you
Michael: So for those who haven't come across it, first of all, what is bit bucket, and then what is bit bucket pipelines?
Guust: Well, before you answer what is bit bucket, maybe we should even answer what is Git, and what is [inaudible] [01:35] For those who haven't heard about it. The last few years [inaudible] repositories are central place where you can host your teams, or your individual codes for a project. And one of those solutions for doing that is Git. Git's been very popular last couple of years, and a lot of people are using it very actively. There are a couple of cloud based solutions for Git servers, and one of them is a very well-known one is GitHub, but the other one you could say is the clouds Git repository by Atlassian. And so, that's what Git does solution to host your Git repositories, your project actually. And then pipelines I guess what’s Git pipelines?
Well [inaudible] pipelines one of the features on top of bit bucket which allows for continuous integration and continuous deployment directly all your Git repository could. Let's say that continuous integration, and continues deployment has been around for a while already. But in the past, the solutions for that when most of that were in general separate products. There were a couple of well-known ones definitely in the Java world; Jenkins for example. Atlassian has it’s own standalone product [inaudible]. But nowadays, they've delivered they’ve created a very cool implementation directly on top of bit bucket. Directly on top of your Git repository and it's really pretty cool. Pretty cool to work with, use, and an easy. It's most important.
Michael: Well, yeah tell us a bit more about that. And we'll talk a bit more about what continuous integration is later in the episode but.
Michael: Why do you… as a ColdFusion developer, why do you like using pipelines for doing continuous integration?
Guust: Any conference, or any meet up, or any meeting, or gathering of C.F. developers of the last couple of years continuous deployment and continues integration were hot topics. But well, I have various kind of projects I worked for big clients, big projects, smaller stuff that I handle on my own. But what I've noticed in general is that if you have like these big projects as a developer in a team, I'm not so… I'm not always directly involved in the deployment and integration and everything. So, I haven't really touched it on that level and a lot of the time, I wanted to start using those techniques for my own projects. But it's pretty big investment that [inaudible] time wise to get started with setting up your own server, maintaining your own server, keeping track of it, and getting them familiar with it.
So, that's why I never really picked it up for my own project and that it's with the pipelines effect that it's really easy to use, and it's directly on top of your bit bucket repository. That combination made it an ideal first step for me to like actively start using those techniques for my own project even very, very small projects. I think one of the first projects I started using it for was a simple static website. Nothing special about it. But it allowed me to like to run a couple of tests on it, make sure that everything works, bundle it nicely, and immediately deploy it. All of that done straight out of my Git repository.
And one of the reasons for that, one of the reasons why we have bit bucket pipelines now is and why it didn't exist earlier is because it's been… it's really leveraging the evolution we had with containerization recently. And so which means that it's strongly depending on the Docker stack, and that's a really cool feature because it allows you to whatever language, or environment you were. If it's ColdFusion, or frontend development, or python Ruby on Rails, dot net Java; doesn't matter. You can do. You can basically you pick a container you start building your pipeline on top of a container, and you can really leverage all there is the old the container officer right away, and that's really powerful.
Michael: Yeah, Docker containers are something that ColdFusion developers been using more than last year or so. And I know [inaudible] [7:22] did a whole month of webinars on Docker container. So, we'll put a link to those webinars in the show notes for people interested in that. Some really cool stuff there. So, tell us a bit more about what continuous integration is, and why you like doing it because not everyone listening might be doing it, or even understand quite what it is.
Guust: And the whole concept is to make sure that you're out to meet part of your workflow and definitely everything that happens after you've developed, and written your code. So, if you're working with a lot of tests, if you're working with a test driven development cycle then especially at that point, you want to make sure that you run your tests. You know how to make the process if you're running your tests on every time you change your code. And you can definitely do that locally, manually, or have something what's your files and when it. But even better is if you can just like when you wrap up something wrap up something. And that's why it work so closely together with your Git repository. You should commit to your repository.
And all of that can be handled as well in that continuous integration and continuous deployment flow. Even up to the point where you can… you know to make the deployment itself. It shouldn't when you have an update ready that it's immediately deployed in your test servers, you don't have to take care of that. You don't have to do those actions manually any more. And it's definitely something you can really get an advantage from if you're working by yourself on your own projects. But even more if you're working in teams. Make sure that your code is tested, and you have a pool requests ready that it's tested, and that it's validated that way before it's integrated into your code.
Michael: So, it really automates all the steps you might have done manually of testing the code, and sending it to a staging server, or in any other things that need to happen. And so that's continuous integration. Is continuous deployment something slightly different?
Guust: It's actually it's the next step. If you do the integration, you do the deployment, and that's something you can automate as well. What we see and what… of course doesn't work for every environment or what we see a lot of companies do nowadays is like it really small changes and immediately… Like even if you release them on a production I think they put through cycles of course of testing and validation. But to work with very small batches of changes and to have the continuous flow of deployment.
And if you want to do that, you need to automate or you have a full office of their thoughts guys were constantly pushing buttons to make sure something deploys. If you take it to the extreme, you have the example of Amazon of course. I think they're releasing every second or maybe like five times a second on average. So that gives an idea of how far you can go. But it all depends open source your project, your case, your team of course. But without a [inaudible] that flows is really interesting.
Michel: What kind of problems does it avoid by having automating it?
Guust: I wouldn't say so much of avoiding problems. It's much more like smooth. It's a smoother workflow; that's it. So, it makes it easier to have the whole movement towards production release more than it’s solving problems
Michael: Okay, I just wondered if sometimes people when they do it manually, they forget to move a file over.
Guust: Oh, yeah of course! If we're going back to… If we're looking back at like copy and paste with an F.T.P. server, definitely, this automating is much more error safe, but good. Like comparing it to a deployment which is already automated, but like maybe not happening automatically then there is… then it's much more of a comfort thing to have it all done automatically.
Michael: So you're basing all lists are it all runs on bit bucket as a repository. So, what do you like about bit bucket as opposed to say GitHub, or some other repository that you might use?
Guust: Well, they're all Git repository. So on that level, there isn't much different. One of the reasons I've used GitHub for a lot of stuff maybe for open source. Recall stories is stuff that are developed and of release open source or helping out on other projects what you see is that. You will get help with the first big one out there. So a lot of open sources in there. So for vision visibility as well it's really interesting to host your open source projects. The reason why in the best serve working with [inaudible] [14:13] that ticket I saw it well you mentioned earlier that by my name sounds Belgian, it’s actually Dutch.
Guust: There… and I am Dutch. The reason why I started work with bit bucket is because at the time and still today, they are for private repositories on their free plan as well. They have a slightly different business plan where GitHub is more about the amount of ripple stories you get on both, you get unlimited public repositories that with GitHub would get it up it's you're more than limited in the amount of private ones based on what you’re paying. Well, the much more on the whole Atlassian idea of how many users are using it. So the reason why I had at the time I started using bit bucket for a couple of private projects is pure debt. But nowadays if I [inaudible] [15:14] me to choose, bit bucket has a couple of really cool features with one of them being the whole pipe lines.
And that’s a really nice like solution on top of your repository. So, that's definitely why I like working with bit bucket. So, yeah they… by the way they… This is really recent. Couple of weeks ago, they activated the whole Atlassian box trail the very famous and well-known project management tool and the integrated that would Git repository as well. So, they're on top of your Git repository. You don't only have pipelines, bit bucket pipelines, but you have like Trello board as well. You have an issue trekker and you have a lot of functionality all around you as repository too. So I have everything in one place.
Michael: Where is the issue tracker [inaudible], or something else?
Guust: It's similar. You can integrate it with … of course but what would you get out of the box and free is that not the full blown [inaudible] of course.
Michael: Okay, so it's like a cut down version.
Michael: And then, do they provide support for it, or have?
Guust: It's a good question. They have very good documentation and that solved all of my issues, that's for sure. When I started playing with bit bucket pipelines at the time, it was still [inaudible]. So, there wasn't that much information there on that it's pretty easy to use. And most of the issues I had with it were not so much bit bucket pipelines, but more how do you make your workflow, your process, so that's for sure. I'm pretty sure they have support options, but I haven't had the need for them yet. So, I don't know any of the details.
Michael: Right, and then is it free, or is it a paid version, or how does that work?
Guust: The way it works. So you have… you can have a free bit bucket account [inaudible] [17:35]. So, first of all, you have bit bucket, the paid cloud solution which has a couple of plans which may be around how many users are using your repository. The pipelines as an add-on is billed is that you get… It's all about minutes. The how many minutes are you building stuff on top of the pipelines. So, they actually burning off your pipes. You get a couple of them, you get a couple of minutes per month for free. And then if you want to use more, you just have two options, or you start paying more for your bit bucket account, or you buy additional minutes separate from your package you already have with that; with the bit bucket.
Michael: But how much is it to buy more minutes?
Guust: I should have to look it up.
Michael: Or do you… I mean let's ask this question either way. For the projects you do, you end up having to pay for this. Let me ask the question another way. You've run several projects through this, do you end up having to pay much for it or?
Guust: What I think, what I notice in general it's all… It all depends on how active your project is developed. If you work with multiple developers at the same time, well doing like small pushes through the ripples three and then your bill to writing quite frequently so then it might go pretty quick. But if it's in my opinion, it's really… it has a nice balance in a way that if you're working by yourself alone on the project. The minutes you get per month, those will get you pretty far. If you work with a bigger team of course and then, you’ll probably have to buy some extra minutes.
And another thing as well is that what I noticed personally is that when you're setting up your pipeline at the beginning, you do quite some testing. Make sure everything's tweaked and working correctly. That's a period in which you are quite using quite some minutes as well to make sure that everything runs smooth. You could… There is a way to avoid [inaudible] [20:06]. They have this way you can actually test and build your pipelines a locally with your local machine, or Docker containers. But I'm just being very honest. I never did to that and just like they did write on the repository build it a lot with [inaudible] [20:27].
Michael: And you know I looked at their pricing page on their website and we'll put that in the show notes. But you can have several users. It looks like five users on there for free. You know that's starter level. Or if you need to go beyond that, it's two dollars a user a month. And if you need extra minutes, you can 1,000 build minutes for ten dollars. So it doesn't look like it's particularly expensive to…
Guust: No, no that’s something I really like as well.
Michael: yeah cool
Guust: Which makes it really… And what I said at the beginning, where in the best the solutions where you actually had to set up your own servers, and spend a lot of time, and money as well to get it up and running. For me, like the way you get continuous integration, and continuous development with bit bucket pipelines makes it like available for the masses for like small developers all around freelancers, smaller teams or even people like coding for fun.
Michael: So, when you're doing this integration, you’re using Docker containers. Where are you running those? Are they on a personal cloud, or somewhere else?
Guust: So, the containers for the integration, containers used by bit bucket pipelines, bit bucket takes care of it. So you don't have to do anything for that. You don't have to host it anywhere. So, and the next that I used Docker containers a lot in my projects, and that's the third. I have both and so the G.P.S. service for containers almost as well as some AWS infrastructure. The way bit bucket built, had built it pipelines is that the whole infrastructure for pipelines is really on top of AWS as well.
Michael: Oh okay, so it's easy to integrate in with that if you want to.
Guust: Yeah but…
Michael: You can really use any cloud deployment you want to.
Guust: You can use any cloud deployment you want to do if emission that like the deployment. You're not even obliged to use the Docker containers for it. The cool thing about bit bucket pipelines is that it's usually using Docker containers itself and that makes it really, really flexible. But there is a nice integration as well with the whole container concept which makes it possible within your pipelines to create those containers, and to then ultimately deploy them as well. And do you use this with teams as well as yourself, or?
Guust: Mainly by myself.
Guust: Most of the teams… There was one team last year, they would have probably gone for a bit bucket pipelines. But at the time they started the project, it wasn't available yet. So, they had just set up their agenda servers. So, they saw the value of it, they just didn't switch anymore because the whole thing was set up. The moment you have your set up, you just maintain it, and it's a big investment if you want to change that so it's especially with a big project as the one I'm talking about. I mean general, the vast majority of use cases I have is with personal projects. For small projects, small clients except when working on my own.
Michael: But what's the advantage then of if you did use it on a team.
Guust: Definitely the effect, well when I'm working by myself on projects, if an integration or deployment needs to be done, it will be me all the time. So, I know what I'm doing and I’ll have to do it. If you're working in a team, then you immediately. If you want to every want to be able to do it, then you need to train everyone. Everyone needs to be sure they know what they're doing and so and so by automating all of that, the need for that goes away.
If the fact that you can run the integration with the tests and everything, make sure that everybody’s code gets tested before it gets introduced to a base. And it's like security, code security leader you can get. Of course what we're talking about and this is more the case with front end development. And for example: if you're looking at code formatting the interest; stuff like that. You can run all of that as well during your integration to make sure that everything's really nice and smooth before it enters the code base for serious.
Michael: So, it lets your team be more efficient.
Guust: Yeah, yeah, that's for sure.
Michel: Yeah, and you mentioned you use it with Docker containers. I noticed on their website it also integrates with Docker hub so.
You can immediately run PM install which installs all of the dependencies. And build on top of that to web your tests, your build scripts, and everything. If you have a Java project for example, you start building on top of a container which level Java [inaudible] and you can start like you don't have to take care of that anymore. I have a couple of purchased for a work a little bit with Python for like some scripting and stuff. And there I just take container which is Java. So I immediately have the package manager for Java installed which I think that goes really smooth. The same exists for ColdFusion as well.
One of the things I've been playing with last week and a couple of other people in the community that have done the same thing already as well is to use a CommandBox Docker container as a starting point for bit bucket pipeline which immediately makes the whole box environment available. Which allows me to do a simple like installation of ColdBox, installation of TestBox, run my tests on top of the building server that you have with CommandBox. And otherwise, if you want to do that, run those cultures and tests for example. You would… or you would use a container which leverage ColdFusion without a ColdBox, without CommandBox you could do that as well of course.
Of the just to make sure you have that container, the official Lucee container of course. But for other …cultures. For example: it's only a roadmap, but it's not available yet, and that makes it really easy. There are even a couple of cases where I haven't done it yet. I've done it in the best, but I haven't done it on any pure project is to where I would build my own container and use that. And that's another thing you could definitely do, and make sure that it all ends up in faster pipelines. An example for that is if you would like… start off a python container, you want to use that AWSCLI to make sure that you can do a deployment really easily.
What I should definitely do for myself over of the next week is actually make myself Docker container which is built on top of the pipeline, and it has the seal I installed by default. Of course, I'm then responsible myself to maintain that container for my deployment. But that doesn't mean that every single pipeline which is rented which is using AWSCLI which is [inaudible]. I don't have to install it anymore which makes my build go faster which is cool because then I have a quicker resulting, quicker feedback. But it also makes it less expensive for me to run those pipelines because they consume less time.
Michael: And then if you're using this with a team, do they all their bills go in a queue, and you have to wait, or is it all happening at the same time?
Guust: They're… Well, the buckets are manages to load with a queue. So from time to time, I have a built which is like in a queue. It's like waiting to get some processing power. But in general, that has always been less than like a minute or two. Most of the time, I'd immediately get that computing power, and the bill for instance immediately. And also, maybe something I'd definitely explain is that those bills are triggered by your commits, your cautious to your [inaudible] [30:57]. So when I go change, I make commit. The moment I push the commit to bit bucket, that's when it immediately triggers the bill to happen which is something with other tools like Jenkins, and Bamboo, and so on is something you need to configure and figure yourself to happen.
Michael: And so you use commit your changes and then it goes has been test sets and deploy it. How do you get feedback as to whether the tests ran okay?
Guust: That depends how you run it. You can go to the interface and you can visually see it. You actually get the whole output of everything that happens if you that. The way I have it configured if I have integrated like with a couple of my repository so that I get a notification when it build starts, when it builds, and when it’s succeeded. And I always have to figure that the moment a built fails, I get an email address. There's the bill for a lot of stuff, and even notifications which isn't always ideal. I know but it's something I would oh of always open source that would get some immediate feedback.
Michael: Cool! And then, when you're building this pipeline, are you writing some kind of scripting language, or how do you create the pipeline?
Guust: It's a YAML configuration file which is basically it's like… It's some kind of coding style where you actually define a container, and then you can explain like list all the different steps. What I've done in a couple of cases is that I could list every single step along the way. At the moment that my pipelines get bigger, I tend to like just put everything in a better script and excuse the better for my pipeline which makes it a little easier to maintain because you keep your configuration a bit smaller.
Michael: cool okay
Guust: One of the cool things as well is that you can actually… You can configure your pipeline based on your branch. So what I do, what I personally always do with Git is that I have master branch. I also for the developed branch, and feature branch for the different features I work on. And then in my preferred ration file for my pipeline, I have a standard. The standard steps which are executed on every single branch. But I have a specific configuration for my developed branch, and a specific configuration for my master branch.
Where in some cases the developed branch will either deploy it on the test environment, or on the acceptance environment where the master branch would deploy in the production environment. And then, the future branch as they did they’re always run the tests make sure that everything works fine. Maybe make it built to make sure that it's working fine. But I don't do any deployment of those. But the moment a feature is ready, I merge the branch in to develop there it gets tested as again gets billed again, and gets deployed automatically. And the moment I want to release to production, I just merged my developer engine to my master branch, and it's all done.
Michael: Cool! Anything else you want to share with our listeners about bit bucket pipelines?
Guust: Let me quickly think if there are any of the features of what… I shouldn’t tell everything because people in two weeks won't come to my sessions anymore at C.F. Camp. But a really cool feature which is currently in Alpha. You can actually… you can ask for Alpha axis and I don't think they'll… I think that gave it away if that's just as for. I got it that way anyway. One of the cool features in Alpha currently is that you can actually split your build up in steps which is easy for organization to have like a testing step, and then a building step, deployment step.
The really cool things you can actually subtly different container to be used for those different steps. Which means that for a node js project for example, you can build your test step on top of a node js container you did say it was your built step. And you build everything on top of the js container. But then for deployment step, you could actually use python container. We use Amazon CLI, AWS CLI to deploy your finished product straight on to an S-3 account for example, or anything else. So that's really cool.
You're basically everything looks single comment, you're executing is just like the comment, the identical to the way were doing in a terminal. So, anything you can do in a terminal, you can do in your pipeline. So, I have a cases where I do S-3 deployments for other stuff excite and I just once it's been built, I take everything, and I wipe out. And they do this three buckets and put everything the whole built in there, and then let AWS know it needs to refresh it’s sketch, and then my built is done. I have other cases where I also deployed… not really deploy, but I use as free as like an art factory to put a zip of my built so that they're all listed over there. I can pull it. I've separate deployment scripts for it which are not integrated in pipelines because the servers aren't integrated.
Michael: So, if someone listening was curious to get started off with bit bucket pipelines, how would you recommend someone get started with it?
Guust: Well, open your bit bucket account, or create one if you haven't. Go to your repository, and on your left in the menu below is bit bucket pipeline, and you'll notice by pints. If you click on it, it already has a small introduction and you can… If you’re activated on your repository, it immediately helps you out defining the base of your pipeline and then circulate with it. And look around to documentation. You have tons of examples in the documentation. How to integrate AWS, how to integrate with what stack for example. It's all described in the documentation. So it's just… it's easy.
Michael: Okay, and roughly how long does it take to get up to speed with this?
Guust: It all depends how complex your pipeline is. [Crosstalk] [38:22]
Michael: Simple pipeline just to get started.
Guust: If you have a front end project where you just want to run your tests every time you do a commit, that’ll take you half an hour to get started. You just follow the starter, the wizard on your bit bucket account, and if you take node as your container, it will immediately suggest to do like an MPM install, MPM test, and you’re done.
Guust: It goes really, really easy. It gets a little more complex once you need to integrate with third party instead with AWS. If you need, when you need to like install the CLI, make sure you know what to do with the CLI. And the [inaudible] [39:13] that's much more… those are much more difficult it's around the characteristics of AWS,wou ja zip of..bucket. the deployment then runs on the bit bucket.
Michael: Cool! Well, this is good. Let's change gears a little and talk a bit about ColdFusion. If that’s okay. So, tell us why you’re proud to use cold fusion cast.
Guust: It’s because it solves every problem which is thrown at me which is true. I think that the most important thing is super flexible, and I can do anything I want with it. Of course there are cases where other technologies, or other solutions are more appropriate. But that it got me started. Start my career, and I've been able to do everything I needed to do until now so. We all know the situation with ColdFusion which is still the most popular language. So I always keep an eye out on what else is there. But I haven't really run into anything which is that easy to me to use. So haven’t… I still love it, and I’m not walking away from it so.
Michael: Great! Yeah, I mean some people have said ColdFusion is dying. But I think you know, as the title of this podcast, ‘ColdFusion Alive’ I think it's actually alive. But let me ask you, what would it…
Guust: Every language is dying if you get it. The only stuff which is popular nowadays are some of the new cool things. And in general, a lot of the innovation is happening on the front end anyways. On the back end, it's all business as usual. But ColdFusion still does it and there are still several mainframes running on COBOL. So, you can even that doesn't go away so.
Michael: Yeah, it maybe programming languages never go away.
Guust: No, they never go away. There's always somebody who has use for it, so that's for sure.
Michael: But let me ask you, what would it take for ColdFusion to be even more alive this year?
Guust: Ah! Good question. I think adopting modern techniques is the most important. I think that for a certain period of time that something which hasn't really happened with it in the ColdFusion environment, not in a community, not with the vendors, and that gave us a little you know… a little [inaudible] on a couple of things. If you look at what happened the last couple of years with command box, CLI tool with the whole box ecosystem as a very, very enterprise framework to work with.
The Lucee containers affected the Adobe’s, ColdFusion, Docker containers that's something that needs to happen. And we just… we need to make sure that we catch up, and we stay modern with those techniques. Look into ways how we can make sure that the ColdFusion is ready for the modern architectures software development. And prove that it's capable of working in those situations as well. I think that's the focus should lie there.
Michael: Great! Well, that makes sense to me. So, what are you looking forward to a C.F. camp this year?
Guust: The first think that popped in mind was the beer.
Michael: Well yes, in Munich, that is true. In October which could mean the could be some October fest.
Guust: No, unfortunately, the October fest actually happens in September so…
Michael: Oh! Had me fooled there.
Guust: Yeah, I thought the first time I went to Munich for C.F. Camp, I was like, ‘October!’ Now I know it's for me first of all, it's meeting people. It's in Europe, it's the meeting place to meet people from other countries that are working with ColdFusion to see some familiar faces again, or people… Several people I'm meet over there are people who I only see once a year at C.F. Camp. So, catching up is a really cool thing. But the content this year looks really promising as well. And a nice balance between the different subjects. So, I'm definitely looking forward to the make sure that I attend as much other sessions as possible. I tend to always skip the one before my session, and after.
Guust: But before because I'm stressing out, and the one after because I’m decompressing, and reeling towards beer.
Guust: My session is in the afternoon as it is this year. So yeah, it's… And it's a very nice location and I'm specifically looking forward to the fact that it's sold out this year.
Guust: It's been announced a couple of hours ago. It's sold out for the first time in history, so it's going to be the largest crowd ever. So you see, ColdFusion isn't dying, and certainly not in Europe.
Michael: That is great! So, if people want to find you online, what’s the best way to do that?
Guust: I have a Twitter account which is [inaudible] L A G A F F E. That in general is my nickname around the web. I have a website [inaudible] where you can find links to words or my social media accounts, and so on. So you can follow me all around the web that way. And other I’m in the CFML channels of course. But not always super active and I'm pretty busy recently with a lot of works so. But whenever you want to reach out to me, make sure you just tag my name somewhere in the channel, or send me a direct message out. It'll become a notification on my computer, and on my phone, and on my tablet so. If I'm ignoring you at that point, then something in private life is more important. But otherwise, I should be…
Michael: yes may…
Guust: … really pretty quick
Michael: Maybe you're out at the orchestra, or playing on your bass.
Guust: Indeed [inaudible] to music.
Michael: Great! Well, thanks so much for coming on the podcast, and good luck with your talk, and…
Guust: thank you
Michael: I hope to see you another time.
Guust: Cool, for sure.
Michael: Okay, talk scenes.
Guust: bye bye