 It's 11 o'clock, so I guess we'll get started. Let's see what happens when I press play. All right, when I press play, I think I'm gonna have no control over anything. So thumbs up if you can still see the Functional Group. Okay, great. Okay, Functional Group Update May 1st, 2017 for the front end. So we've had some, this is first the accomplishments. The teams have split, but the front end is still considered one team. We still meet all in on Tuesdays together, but we're just splitting some of the teams. So team AC, which is Tim's team, which is Prometheus Marketing Platform and Edge, which the biggest of those should be platform and marketing and team DC, which is discussion and CD. So the four teams Edge and Prometheus are currently small. So that's why you can have the four teams and the two teams together. It's because discussion and CEI and CD are large. So some other accomplishments, things that are out of the box, a lot of people have already talked about the features that are going in this release. So I'll talk about some things that we're doing that are a little bit out of the box. We've done some non-code file renders, which is what GitHub calls non-code file, non-code file viewers, which is just basically anything that's like a binary or something that's not code and ways to view them. So we've, this month we've added XML, zip and DXF that you're still in review, but people really liked the sketch file viewer and the other viewers that we created. So I figured I'd add a couple more. The review process has improved for view because not everybody is an expert on view this moment. We have a special process to make sure that everybody writes view in the way that we want them to. And we've also improved the docs for view, which you can check out on the front end docs in docs.gitlab.com. We're currently testing out splitting MRs for the merger quest widget. We split that MR into, it turned out to be an enormous merger quest. So it wound up being split into 15 different smaller merger quests. Some parts of that were a pain, but other parts of that were really good. The parts that were really good was for the merger quest reviewer. People like me reviewing smaller merger quests and then you can really focus on that individual amount of code, which just helps tremendously. So even though it's a little bit of a pain for the people writing it, I think that's just a little bit of a growing pain. It's new, it's something we have to get used to. And so we're gonna try it again to see if we can make code reviewing a little bit easier. And we are now writing all view in these .view files. What that does is it allows us to write HTML, we're not putting CSS in there, but you can put CSS in there. And we don't wanna do that because we already have our giant CSS framework that is already in place. So whenever people write new code for the front end, they really shouldn't have to write any CSS at all in theory because all the CSS for GitLab has already been written. But with these .view files, you can write the template in HTML, you can write the JavaScript, and then you can import those .view files and they get turned into compiled JavaScript, which is a lot faster than having to render HTML. And currently you can also, in your sublime text or your Atom editor, they do get syntax highlighting. I think we're working on getting syntax highlighting for them for the diff previews and for the repository views. But those .view files make things a lot faster because then you have everything kind of in one file, it's kind of neat that way. Some other accomplishments in the box, instead of out of the box, real time is taking off, we're working on a lot of real time features right now and it's working really well and it looks really good and it's just really cool in general. The merger quest, which it is going in for this, I said we split the merger quest widget into multiple smaller merger quests and we have documentation for that, that is, I don't think it's in that yet actually, I think it's coming up. And then once we get the scheduled pipelines in, this will allow us to schedule cross browser testing with browser stack. The reason that we're using browser stack is because it'll allow us to not have to create a virtual machine to test things in IE and then you can test all these things at once. So it is one thing that we're using that is not open source but that is an external service that we're using but it is also gonna help us with stuff like cross browser testing, which we've been wanting to do for a really, really, really long time and we really, really, really need to do it and there's not any easy way to do it on our own. It would just cost a tremendous amount of money to get tons of VMs. And then to test on things like tablets, you'd have to have what some people call a device lab where basically you have a room that these devices are sitting there for people to use them. And the virtual machines that they create for these devices aren't exactly a one-to-one situation because sometimes they're inaccurate and a lot of the stuff you're testing is like the performance. Does it crash the browser on those mobile devices and that's something that you can only find out if you test on a real device and that's something that browser stack will allow us to do. So that's what we're gonna use browser stack for and we're gonna run that nightly on a bunch of different browsers. We're gonna start it off with IE 11 because that's what we support and we wanna see if we can just catch any of the IE 11 things which I'm sure we're gonna catch a lot of because we currently don't test it very well. Some concerns, we currently over schedule. The bad and the good of this, the bad. We've always over scheduled. However, we're scheduling more and more each release. It's more than people can complete and it's more than people can handle. The good is that I'm now able to help out with deliverables thanks to Tim. And some other concerns is that we aren't officially testing IE at all even though we say we support it but the good is that we're adding in browser stack testing for IE and other devices to catch cross browser problems. Some other concerns is that testing is a huge time killer. The bad is that tests can take over 80 minutes and have to be retried many times over and this is exhausting for developers. Luke has a great point here which he wrote in this merge request. He said, I'm completely and utterly tired of wasting my time chasing pipelines and I'm also sure that it costs us a crap ton of money or he said a crap load of money to run failing builds continuously. This is a real issue that we either need to solve or have a process for because I've never wasted so much dev time in my life than trying to do, trying to get other builds that I haven't touched to pass. And I'm sure that's not just for his own builds. I'm sure that's not just for other builds. I'm sure that's for his own builds. And I think that that's a really good point is just that tests are a major thorn in our side at the moment, there's a lot of, and I know that people are working on the transient failures as we call them. The transient failures is where something's just failing and it's not a legit reason that it's failing. I know that we're working on those but currently the point is that we waste a tremendous amount of time, development time and like emotional time, if you know what I mean. Meaning like the people have a certain amount of reserve when they're doing stuff like this and that reserve runs out very quickly when you get very frustrated with tests. Plans, we're not hiring right now. We have a plan, we have the plan to make it lab faster. One of those things we're using is .view files. Code splitting is where you make sure that only the code that is needed is put into certain, is only put into where it's needed so you only load the code that you need and Webpack can do this. We just have to take the time to do this. And we're starting to AJAX, not all the things but we're starting to AJAX more things. So the link that is in here is for the deploy keys where I took the deploy keys part that was written in view and sorry, wasn't written in view where it was loading all at once and we just make an AJAX call to load the deploy keys which for some people they have a tremendous amount of deploy keys and so we can do this and the page will load immediately and that helps out people a lot. And so anything that's slow, as a first step we can probably make an AJAX call to get the data after the page is loaded. We're also writing a lot of cool features that people love. So that is a link to the .docx viewer. I'm just one of my goals is to just see how many things I can support in GitLab, different types of file viewers. Because one of the things that'd be really great if we could just keep people in GitLab and have them viewing stuff on GitLab. So I wrote a .docx viewer kind of on the side and we're trying to make development faster and easier as fast and as easy as we can. And so anything that we can do to make the development easier, we're going to make sure that we do that. So does anybody have any questions? Let me get out of this thing and let me look at the, you stop screen sharing, let me look at the chat. Yeah, so .docx will be huge. It currently works, but it's also a work in progress because I looked at the .docx file specification and there's like literally thousands of things that I'd have to support. But if we just go for the very basic things then I think that will cover a lot of bases. And yeah, the new blog viewer architecture is what's helping us write these non-code file renders a lot easier. Collaborative editing to replace Google Docx. So this is something that I've been looking at like non-stop, I can't stop thinking about this collaborative editing. Unfortunately, it's really cool. Unfortunately, it's a little bit of a difficult problem to solve, which is why it's a thing called, well, one way of doing it is called operational transformations and it's quite complicated. So I think that we have to come up with a way that is not complicated and we just have to dedicate time to it. But as soon as we dedicate time to it, I'm sure that it's something that we could solve and I'd really love to solve it. It's a super cool thing. Right, and the backend needs to prepare for something like that. And what is the weirdest supported file format in one year from now? That's a great question. I don't know what the weirdest supported file format would be. If you can think of any, I'm telling you that Docx was one of the most fun things that I've ever written in my entire life because if you know anything about programming, you know that Docx is like the devil. It is not something that you wanna just like dive into. And this is probably like the fifth time in my life that I tried to do it. Fifth time was successful, still. Maybe like 3D renders or something. I believe it would be pretty cool. We do have 3D renders, we put that in. Oh, of course we have that, I'm sorry. Yeah, so the cool thing is that, so it's called an STL file and it's the 3D printed. The thing that people use for 3D print where DXF and DWG is the 2D and STL is the 3D, we can support even more 3D type of files like OBJ and Colada files are, I don't know if people still use Colada files. It's been a million years since I've looked at 3D stuff. So the last time I looked, they did Colada files. Yeah, 3DS. So the cool thing is that we're using a library called 3JS and 3JS helped us support STL right out of the box. So it was very, it was pretty easy to do it. And not that we wanna do this, but we tested it with a 23 megabyte STL file and it worked and it was smooth and it was great. I think the blob rendering that Dawa wrote will stop it at five megabytes, but it does work. So it's very cool. Is it documented somewhere? What are all the file formats that we support? Because we should document it. Yes, we will be, but at the moment the only, oh, and we put in IPython, which the only, I think we are on par with GitHub right now. And then once the DocX and DXF and Zip go in, then we will be beyond what they have for non-code, non-code file viewers. So that's pretty cool, which it wasn't particularly difficult, so we can do anything. PST, yeah, PST is known to be the worst file format on the face of this planet from what I've heard. There is, so we wanna make sure that anything that we render that we get it, if it's a visual thing, like if it's a thing that artists use, then you want it to be pixel perfect. If it's a DocX thing, then it doesn't have to be perfect because it's not a thing that somebody drew and they're expecting it to come out exactly as they drew it, although they are for DocX, but just not as, so PST is something that we have to be very careful with because it's either gotta be perfect or not. And that's where the sketch file thing worked is because we actually just took the image that's stored in that sketch file and we pulled it out and we show it. So we're talking to the sketch people right now. We have a contact in sketch, thanks to Dimitri from UX, and we're talking to him and trying to see if they can give us all of the previews, not just the current layer for sketch files. So, yes, so that's that. But if anybody has any ideas, there is, I don't know if Dimitri's on this call, but, and I'll link it somewhere. I'll link it in something. We have a list of things that we wanna support. So if you have any ideas for things that you wanna support, I'll link it in the general channel, the list of non-code file renders. Right, we can do anything. Does anybody have any other questions? Cool. Well, thank you so much guys and have a great rest of your day.