 So, let's start. My name is Yijun Melnikov, and today we will talk about Bluemix Live Sync. A little bit about me. I'm an experienced Ruby and Node.js developer at Altairos. I worked a lot with Cloud Foundry, Bluemix, and I have some IT products under my belt. So, before we start, I would like to ask you if you ever faced environment-specific issues. I think it's really annoying type of bug, right? And sometimes it's really hard to understand why it happens, especially on production. I don't know, maybe it's easier to find aliens in space than why it happens. Let's play a small game. At the left image, we have development environment, and at the right image, we have production environment. And let's try to find all the differences. While you're searching, I can say that on Chromium project and in Facebook, I did a small investigation and found that it usually takes about three days after pushing an issue to assigning this to appropriate team. So, in a big company, it takes three days to investigate issue and assign to developer. By the way, I asked it in Twitter, what is your record of duration to investigate issue in production? But unfortunately, nobody answered. Maybe you could answer now. What is your record? My record is just one day. Maybe someone has more. Maybe someone is still investigating. How about at least a week? A week. Actually, on Chromium, I saw one issue that was assigned to developer after one month. You see, so it's really complicated to investigate issues on production. So let's check what you have found. How many did you find? Four? Six? Oh, great. I think you won Flash Drive because you won all of them. Let's check its spots on Elin. Its color of spots. It's Missing Planet. I think it's the most important issue. And color of stars. So, six. To prove that it's really hard, I would like to tell you my story. It happened in 2010. We implemented an application for... It was port application. We implemented this before basketball championship. And so we understand we couldn't just move the deadline. So we had to do it really fast. And it was pretty good. We implemented all the features. We just deployed last CSS fixes. And basketball fans were going to use... This is the application on Saturday. It was Friday. We just deployed small CSS fixes. And QA engineer checked for regression, for some regression issues. And just in five minutes after the deploy, he came to me and said, Eugene, we have a problem. Nobody can sign into our application. So, nightmar, right? I downloaded database from production. Checked locally. It works. So I cleaned all the cache. I checked all dependencies. I checked all changes in GitHub. And nothing helped. It still didn't work on production and worked only locally. So at this moment I started to believe in magic. So I didn't know what to do. And I thought about praying or changing DNS to my local machine. But fortunately, fortunately, I continued investigating dependencies and found that... And came to the idea to check salt that I have in production that I used for creating password send. It was it. So fortunately, this story has ended. Another story happened to me just about a year ago. We created an internet shop. And this shop didn't have a landing page. So a customer asked us to create some smart landing page. We created it. And he scheduled a meeting with the investor. He wanted to show this. So we deployed it. We had a really tight deadline because there was a meeting with the investor. I was woken up by my customer early morning by a phone call. And he said that we don't have any buttons that follow to catalog. So we need to fix it asap. I understand him because the landing page without any links to catalog doesn't make sense. It's useless. So actually, it was easy to fix. But the problem is that meeting with investor will start in five minutes. And deploy process used to get 10 minutes. So I wasn't able to even deploy without any fixes. So we both were sad about this. But today we will learn how to avoid such situations, how to stop canceling meetings with investors, and deploy your applications and investigate issues really fast, especially if you use Node.js application and deploy it on Bluemix. But first of all, let's revise how we usually reproduce issue. First thought we have, probably we forgot to redeploy. Probably automated build failed. We check environment variables. Probably we have different values. Probably we just missed some variables. We check some logs. We try to add more logs. And if it doesn't help, we start to check in foreign code. Maybe you have some dependencies with updated versions. Probably transition dependencies was updated. Then you try to download production database. If it's possible, if it takes a long time, you go to lunch, because usually you spend half a day on investigating by this point. And finally, if it didn't help, you stage to your container and try to reproduce it there. So let's imagine how an ideal world, our ideal investigation process, should look like. So it should be production environment. Not like this. Exactly production. It should have same dependencies. It should have same build pack, same environment variables, no any processes on local host. And very good debugger, interactive debugger. By the way, who prefer to use interactive debugger? And who prefer cancel log? And probably someone combine techniques. I also combine techniques, yeah. Yeah, usually it makes sense to add some cancel logs. Probably it's easier to find an anomaly. And after five cancel logs, it doesn't make sense to proceed. You should go with interactive debugger. So what do we have in Bluemix? In Bluemix we have a tool named Eclipse Orion Web IDE. It allows us to use Google Chrome debugger. It allows us to restart application without redeployment. It allows us to access web and shell logs without cancel. So we can do it even on vacation. So how does it work? Currently it works only with Web IDE. Previously it used to work with your own IDE because Bluemix had special CLI BL for synchronizing source code from your local host to your container. But after moving from just hub to tool chain, it was broken. What they say is that they will fix it. So anyways, currently we should use Web IDE. All changes in Web IDE apply to your container. And you have a special button to open Google Chrome Inspector. So just add to debugger statement and here you are, you can instigate your issue on production. So how to create tool chain? You should go to Bluemix console, go to services, DevOps, press create tool chain. It has a list of templates, but we need just one tool. So just select custom template, enter any name of tool chain, and add tool eclipse Orion Web IDE. It doesn't have any settings, so you can just click to icon and you will get to this Web IDE. But it has tools for integration with Git. It has GitHub tool. So I suggest to add this. If you use GitHub, you will get to your source code in Orion Web IDE immediately. There is also a tool for Bluemix host repository and other interesting tools. So I recommend you to investigate this. This is Orion Web IDE. You see a list of files, you see that you can edit it and some controls on the top. You can share your tool chain with your Bluemix organization or individual Bluemix users. So they can help you to investigate your issues. Azure has interesting features. It supports hot case, it supports dark and drop-for-loading files. It allows you to work with two files simultaneously. It has very good integration with Git, so you can add even your own Git server. It supports code highlighting through ESLint Directives and it also has turnjs config. So you shouldn't worry about turnproject content because it will suggest you to create this config once you start using Web IDE. Also you see here a folder, Launch Configurations. This folder contains configurations for deploying application to Bluemix. This is how it looks like a wizard. It has just three steps. In three steps you can deploy your application. So most of the fields are similar to Manifest YAML, but if you type some values here, they will override values you have in Manifest. On the second step, you can bind all services you need for your application. And on the last step, look at... Be careful with command and build bug fields. If you specify something, it probably won't work because Bluemix Live Sync works only with default. SDK Node.js build pack. And if you customize command, it probably also won't work because Bluemix customizes command as well. Also, if you need to add some additional arguments to your command for starting application, you can do it using a spawn child product process. And also be careful with memory because if you use trial account, you may run out of memory because in the default build pack, there are some utils that use some additional memory. So Bluemix adds some more memory on what you are using now. This is a list of utils. They are installed during the deploy process. So once you should deploy regularly. DevCutSol is a special util that provides access to other utils for Shell and Inspectors. So nobody can inspect your application without your access, unfortunately. And nobody can access Shell without your permission as well. I think it's good. So to specify a list of utils, you should set environment variable, Bluemix application management enable. Just list them separated with plus sign. And I recommend you to use it, to specify it in a manifest YAML because if you have active development process, you might want to be able to restart your application at any time. Also, there are some utils. For example, trace. It's a special util to set lock level. If you use lock for G, for example. HC for integration with Bluemix Health Center. And proxy util is installed by default because it's required by DevConsole. It's for creating SSH tunnel to your container. If you don't need it, if you want to create SSH tunnel manually, you should specify no proxy. So about controls. First, button. Just enable environment variable. Enable shell inspector and redeploy your application. Next button, really useful. So you can restart your application. In my case, it took just one second. So just add debugger statement or whatever you want. Probably you want to just make some UI changes. And restart it immediately, show to your customer. And third button is for opening DevConsole. You will see this page. So you should enter either your credentials of Bluemix or one-time passcode. It can be generated online. It will work just five minutes. So someone not from Bluemix can also access. After sign-in, you see just four buttons. I think open shell, open debugger, pretty obvious. Restart. Also, obviously restart application. Suspend allows you to run your Node.js application and BRK inspect option so you can inspect how it starts. So until you continue process of starting, it won't start. So you can investigate it as well. And the rest of controls. First button, play button is for full redeploy. Because sometimes your application can be out of sync with Bluemix Live Sync. And in this case, you should redeploy it. Next button to stop application. Next button to open application if it has a year olds. Next button for web logs. And last button is just Bluemix dashboard of your application. Here is how web logs look like. You can see drop-down at the top of page. So you can switch between launch configurations. If you have many launch configurations, you can quickly switch between them and check some differences. And here is web shell. So we can do whatever you want, like in your shell, on vacation, without your laptop. Here is debugger. You just add debugger statement and inspect what is happening. I also added three slides with last features of Google Chrome DevTools. I think it might be useful even for those who already use Google Chrome DevTools. Who knew that it's possible to do time traveling in DevTools? Just one. So you can add debugger statement. And if you just realize that you did it too late, you add a new breakpoint, restart, press play button, and you will be able to stop on the previous step. Yeah. Of course it won't work if you have some random. And next nice feature is stepover async. It works really nice and consistently with async functions. Previously it put you to some other functions, but now you go directly to function you click. And you can step into your async function. You can check result by just by clicking variable. Actually it will be available in next version in 60 version. Now currently it's canary. If you don't want to use Google Chrome Inspector, you can use other clients. You see that five products support Node.js debugging protocol. So Node is expected. It's mainly for previous versions before 6.3. Bluemix supports all versions of Node.js. For versions before 6.3 it starts Node Inspect. And for new versions it starts Google Chrome Inspector. Of course Google Chrome DevTools Visual Studio also supports this. So you can run code in Visual Studio and Inspect. JetBrains and JS Library Chrome Remote Interface. So what about other languages and alternatives? So this feature supported only in two buildparks. In SDK for Node.js it supports faster start and debugging. For buildparks, Liberty for Java it supports only remote debugging. But you can create a stage tunnel on Bluemix. All containers can now use Diego. So it's possible to create a stage tunnel to your container and use your favorite tool for remote debugging. For Ruby it could be BioBug. If there is another option, I just... I didn't know about it, but I had to talk with one pivotal guy and he suggested it just today. It's a CF plugin, CF local. So you can run CF local command if you have installed this plugin. And it will create a Docker container. It will run on your machine container, the same as your production container. And you will be able to use all services that are available internally on Bluemix. It supports not just Bluemix, it supports any Cloud Foundry installation. So it's really cool. And conclusion. I found just two disadvantages, but first disadvantage is just partial disadvantage because they are going to fix it. Buildpark limitation is also partial disadvantage because you can create a stage tunnel, you can use CF local, and you have only advantages. So you can deploy fast, you can debug fast, you have production environment. So it's easy to use. You will have fast reaction and you don't have any magic. So that's it. I hope your next debugging session will be fast and productive. So, do you have any questions? Sorry. I can show you after that. Maybe other questions, I have one more flash drive. Yeah. What do you like to do? When? When I cannot use a debugger. Oh. Is it coming? Is the debugger function coming? I didn't get your question. So the first question is what thing that you cannot do with this demo? So you wanted to see live demo? Sorry. Is there a function that you cannot do using this tool so you had to do something else? So actually, it's really useful for server-side but it's not so useful for UI because you know, you ugly-fi and minify all your scripts, all your styles and it takes some time. Of course, now we have Webpack, it's now pretty fast. Probably five years ago it took a lot of time but you know, you will have to run your separate instance in production-like environment without ugly-fi scripts or you should do regular deploy. So it won't work for UI. So that's it.