 My name is Szymon Koz and I'm a software engineer contracted by Kolbora Productivity. I wanted to talk about tools around the online, which can help you while developing. I will show you a small but very useful app called GTK Tiled Viewer. Then I will show you how you can debug app using Chrome browser and how to do the same on the real mobile device. Then we'll talk about how to debug some integrations, like mobile apps with WebView, which embedded online, and about two other tools called Browsersync, which can help you change the code faster, and Linter, which can help you with compatibility of the code. First thing, you probably know GDB, as most of us are C++ developers. And then when you can debug some backend code, the core in online mode, which is used while tile rendering, and then in the online, you can use this small app, which is just another client, but not written in JavaScript. It's just a C++ app, which uses GTK. You can attach GDB as to a normal application. So it's the command you can use. You have to specify the path to your LibreOffice instance and to file you want to open. As you can see on the screenshot, there are some simple tools to modify the document, the font, or for zooming, you can also click the button where you can specify any unicomment you want to test. But when the issue is not in the backend in the core, you need to somehow debug the JavaScript code. So the most advanced, in my opinion, is Chrome Inspector, which can show you a lot of things. You can debug the code like in normal IDE, and see the printing on the console. You can test. You can see which requests take most of the time. And you can also connect to another devices like Android phones. There are a few tabs where you can see that data. Here is the real example. In one tab, we can debug the HTML. We can modify some DOM elements in this tab. In second one, there is a console. So when we log something, we can see it here. Another tab is the source explorer. So it works like normal code editor where we can put some modification. We can also, in case of JavaScript code, put breakpoints and see the call stack and everything like in normal IDE. And what I said, when we want to profile the application and check what we can improve, what files take a lot of time to load, we can use this network viewer where we can see the size of requests, status, and the time of the order. In case we send some requests and it fails, we see the status. And in the bottom, we can see the devices tab. When we connect the phone, we can see its name and open Chrome or WebView applications. It looks like this. Here, we see the name of a phone, the application with WebView. In this case, it was just a browser and the URL. We can open new tabs or inspect already existing. So it's very useful because we can also use the mouse to modify something here. So we don't need to take our phone and manually try to click on some small elements. We can use the mouse on a bigger screen. Another thing useful in this inspector is that we can switch the mode and we can see how the app will look when we test it on a smaller screen. We can choose some types of phones or tablets here. OK, you have to trust me. It wasn't. Ah, yes. OK, but to have the possibility to use your mobile device, you will need to enable the debug mode. In case of Android over version 4 and 2, you need to open the settings and tap a few times on the build number in About. After seven tabs, you will see new option. It's the developer options label. And inside, you can check the USB debugging. Then you will be able to debug apps on your phone. And also, you will be able to install some custom applications. You will write in Android Studio. But to the second thing, you will also need some fix if you use Linux, because you need to add you the rules. And you can do this on your own, checking the vendor and product ID numbers for your USB device. But it's easier to get the really config from GitHub. I put the link here. It's a database with popular devices, so all phones should work. Next step, integrations. When we integrate online in some web apps, then it's enough to use inspector in the browser. But when we have the native Android application and the web view, then you can also use Chrome. But to do this, you need to build of the application with web view debugging active. So in the code, in native app, you need to put something like this to enable it. And then you will see here the name of your application and the possibility to inspect that content. Another tool I wanted to show you is Browsersync. I integrated this on during the Hack Week sponsored by Collabora Productivity. It was annoying to restart the server every time when I made even a small change, when I wanted to be sure that everything is fine, because I had to close the server, restart it, wait for our checking for some unit test sometimes, and then open, again, the browser, open the same state, for example, some window. And then I was able to check something. But this tool, there is another partial solution. We can use the Chrome inspector and modify the CSS there or some properties of one node. But then we have to remember that we need to copy that to the source code. So it's easy to forget something. And sometimes we will not see the whole thing, because something is changing in the time. So better option is Browsersync, which can automatically reload the content you see in the browser when it detects the source code change. I prepared a video where you can see how it works. We need to run the server with a special parameter to serve files directly from the disk, not from any cache. And then we can run Browsersync proxy. Then when we modify the code, in this case, it's CSS, we will see the effects just after saving the file. In the console, we see if there was some change. It also works with JavaScript, but then Browsersync will reload the whole application, not only that part. But it's still faster than doing this manually. So how it works, Browsersync can work in two modes. It can be standalone server and serve some files from directory, or set up a proxy. So I used the proxy, and in the browser, we open just another application on another port. In this case, it's 3,000. And Browsersync, in the background, checks all the time if some files are updated. And in that case, it fires some refresh event to some JavaScript, which is served on the proxy application. So it can reload part of the window. To integrate this into online, I needed to add some change to make files. Because before we copied source files from original files to the destination directory where files are served, but it doesn't work because when you modify something in original file, then it doesn't detect that change because it's another file than that one, which is served. And if we modify something in this destination directory, then it's not tracked by a git. So we cannot commit that easily. We could, of course, copy the file, but it's not a good solution. So I modified the make file to make symbolic link to the original files instead of copying in case we enable Browsersync. To enable it, we need to add enable Browsersync switch during the configuration of a project. And what's important, if we already built previously the application, we need to make clean to be sure that no file is in the destination directory. After configuration, we see the summary where we can check if Browsersync is really enabled. And we can see additional make target with sync writer or calc impress, which starts the proxy with the application we typed. Of course, we need two consoles, one with the server. So we just do make run. And another one with this proxy, with make sync writer, for example. The next tool, it was already in the project for a long time. Linter has linked. But it checks mostly the code formatting, I think. And I noticed a few times that we had some functions in the code, which doesn't work in some browsers like Internet Explorer 11. And this causes some bugs on that platform. So to prevent that mistakes, I propose the patch on a grid with some plug-in to the S-link, which can check compatibility with browsers we want to support. As you can see, it shows some warnings and specifies in which browsers it doesn't work. Of course, these are all new warnings, not errors to not be annoying while developing. And the configuration is really powerful, because in browser-released RC, we can specify not only the one version of, for example, Firefox on Chrome, but we can put, for example, last two versions of each browser, and not that browser, something like this. So I think it's a very good feature. I want to merge this soon. And that's everything I prepared. Any questions? Thank you.