 Let me see if I can figure out how to silence everything. All right, I have do not disturb on this. See if this works. Okay, this is the functional group update for the front end. My name is Jacob Chess and the lead front end engineer. I'm going to share my screen. Can you guys see my screen? All right. Okay. So the front end update March 27, 2017. There's been a bunch of new features that have come in. Everybody has already talked about this in a new blog post. And I have a type of there. But some of the really, really interesting ones that are fully focused on the front end is that the merger quest has been redesigned the merger quest widget has been redesigned. And refactored in view, which is very, very exciting. So for this, we rewrote it in view, which is going to set us up to do stuff in real time in a very, very easy way. And it's going to be very exciting. Anything post your questions in the chat. I can check it after I can't really check it during this for some reason. So part of that was a complete rewrite by Fatih. And the backend sending data in a different way. And this is going to make the, I mean, the one really big thing is that when you click merge, it will not refresh the page, but it will just happen on the page. And because we're pinging for a merge that pinging can then be turned into the real time stuff. So that someone else who's looking at the merge request will also see that the merge request has been merged. So it's going to be a complete rewrite by Fatih. And it's going to be the same exact time at the same exact time, which is very exciting. And in line with this, we're going to real time, all the things. So we have some documentation on how we're going to real time, all the things. The first thing that we're starting with is the title of the issues. And then we're going on to the description of the issues. And we are going to, let me see if I can get back. Okay. So the issue titles and the pipeline index page are going to be real time. Then we're going to move on to even bigger things to real time once. So we're working with the backend team with Sean and everybody else to make sure that we're not killing the server when we're doing this real time. So when we do this, we can set a pulling interval that can be set by the infrastructure people so that if it turns out that the calls are too heavy or we're calling too much, then they can change it to a different number. So this is a really cool feature so that when we put this in, it will work really well. So we have documentation on how to do real time on the front end. Philippa has created a couple of libraries so that anytime anybody wants to implement real time, they just use your library and they call one thing and it just kind of works really, really well. So it's going to be really easy to implement real time on the front end. Winnie Hellman is joining in May. He's actually already joined, but he's going to be starting in May. He's been a longtime contributor and collaborator and core team member. We put in some new front end dots so that everyone can write view because we understand that view by itself can be maybe a little overwhelming, but we think that it's really easy. We put in some new front end dots on a style guide on how to write view and how to make your front end code really pretty and be proper so that when we review it, that it's right. And how to convert things that are currently existing into view and how to just write view in general. So the goal is that similar to the way that CSS works, when you write enough CSS, you no longer have to write CSS, you know, the CSS is in there. All the styles exists. So you just latch on to existing things. We're trying to do a similar thing with view where, you know, we've written the way to do real time. So now you just call things that exist. No reason to reinvent the wheel every single time that you do real time. And the same thing with view. We have style guides. We've written stuff in few before now a bunch of times. You can follow these steps to do things in the same exact way that we've done them in the past. So that front end people can write back in code, backing people can write front end code. UX people can write front end code. Everybody can write front end code. It's going to be very exciting. So Bryce is working on performance monitoring. That's going to report to Prometheus. And that is currently in the works. It's almost done. And that is also very exciting because we're going to find out, we've already found some things that we can definitely improve on the front end that are real numbers that we can change to make the front end even faster. One of the things that we've been wanting to do since the day that I joined GitLab is to test properly on IE Edge and any windows IE machines. ID is for anybody who doesn't know a very difficult browser to write for. Each version changes lots of different things. And, you know, every front end engineer has probably had experience with fixing IE things. To say that we properly support IE is not 100% true at this point because we don't properly test on IE. And sometimes we'll find out things that don't work on IE. We don't have a really good way to do this because testing on IE is extremely time consuming. So what we want to do is we want to do proper testing on IE. So we're getting a virtual machine that's just going to sit there. And we can test properly on that. We'll write some tests for the IE machines to make sure that everything also works on them because a lot of enterprise customers do use IE. Edge is a lot easier to deal with. That's why they made Edge to kind of get rid of the crap that was IE. So now we'll be able to properly deal with this. We currently support IE 11. So we now have front end architecture experts. So if you ever have a question, if you're ever going to write any front end code that involves some sort of architecture, you can talk to somebody on the front end architecture team. You can look on the team page. You can see who is a front end architecture expert. And everybody has their different skills. I like to think of it like Pokemon cards. Everybody has different skills that they have acquired and you want to use those people for their skills. So for example, a lot of people are really good with Webpack, but Mike Greiling is really, really good with Webpack. So if you have a Webpack question, we can ask him and when we go to write stuff that involves architecting for Webpack, we want to make sure that we just talk to him because he's really, really good with that stuff. And so that way, all of our front end code will be at the highest quality, even though it was already very high quality, it'll be even higher quality. And we've documented that under the architecture section of the front end guide. One of the things that I'm really, really interested in, I've always been a really big fan of just writing renders. I'm kind of a programmers programmer. I like to write things that programmers use. So if you look at that link, you'll see all the, what I think is all the non-code files that GitLab supports rendering. I think we can easily support much more than that. I don't think it's particularly difficult. Phil Hughes has come up with an excellent way to deal with JavaScript renders. So when we want to render something in JavaScript, when we want to render something in JavaScript, we will use the JavaScript library and Phil has this way of just putting the back end code in there and it just kind of works really well. So as long as we have a renderer for JavaScript, we can, you know, write, we can have something that renders it. So we're going to start with the IPython notebooks. This has been a super huge requested feature. And PDF as well, PDF.js is written by Mozilla. It's very well supported. So there's absolutely no reason that we can't do that. IPython notebook is not a particularly hard thing to render. It's a really, really fun thing to write. And so we're going to deal with that. And Phil and I together wrote an IPython notebook renderer. We did it in like a day. It was really easy. I started looking at all the other things we could render. It would be really fun to like show Photoshop files. The specifications for that are online. They've been updated in August of 2017, 2016. So why not render Photoshop files? I wrote a Photoshop file renderer in ActionScript way back when, so I'm pretty sure I could do it again. So why not render AI files? There's so many things that we could render and show properly. And then we'd be really ahead of the game. UI Polish, not Polish, the language of Poland, but UI Polish. We are working on a bunch of Polish issues. We frequently get the comment in Hacker News or in other things that the UX is just not polished. And so every front-end engineer has taken on at least two UX Polish issues. A lot of them are really, really easy, just moving stuff around a couple of pixels. And all that little stuff just makes a huge difference. So we really want to focus on that as well. We're currently hiring a front-end lead. We're currently interviewing and that is in the process. It's in the works. And we are not hiring any other front-end engineers currently. That position is currently closed. So that's it. Any questions? I will take those questions. Let me take a look at the chat. The release that you'll see. So you're going to see real-time in this 9.0 release. Just a couple of things are going to be real-time. And from there, we're going to start planning on just accelerating that. And that we start doing a lot more. So nine, nine. No, sorry, nine one, nine one. I get in the release is confused now with this whole seventh thing. I don't know what's going on anymore. So Jim is asking about, can tell Microsoft about this? Is that the Microsoft? Is that the IE testing that we're talking about? We already support IE, right? But we're going to, we want to fully support it so that we don't like have these massive, but we don't want to have any surprises basically. We want IE to be fully supported because we know it's a huge enterprise thing. Yeah. And the experts, a stethoscope may not be included. Right. Python notebook is a Jupiter notebook, which was originally Python notebook and stuff like that. Yeah. We could render sketch files if we can figure out their specifications. The only problem with those things is that sometimes these specifications are closed, meaning that like you don't know how it's written like DXF you can see because it's a ASCII file format, but DWG, which is the same thing as DXF except it's binary, which are CAD files. There's no open specification for that. So it's really hard to render that stuff unless you're Autodesk, but I think it would be awesome to render DXF files in the future. Will I be co-lead with the new front-end person? Yes, I will be co-lead with the new front-end person. We will be splitting the team and people will report to me. People will report to the other front-end person because currently we have 17 people that are reporting to me. And oh, they have a JSON app. Great. Well, I'll take a look at it and see if we can render sketch files. That would be, yes, it's too many people. It's clearly too many people. I'm fully aware that this is too many people and we know that. So any other questions from anybody? Great. Well, thank you so much for joining the front-end functional group update. See you guys in the front-end call. Thank you.