 I think the correct answer is to get wireless display everywhere, that's really what it should be because I feel like with all these stupid dongles I have to carry around or like depending on the port, it's actually kind of shitty, like that's the problem, so I don't know. We used to have, in meeting rooms we used to have these dongles that were like 10-15 dongles just because, like everyone's laptop had a different thing, so a display port and like full-size HDMI, small-size HDMI, this, that, the other, and we break those dongles all the time. Yeah, really? Yeah. Sure. Is everyone back? Yeah. Good enough? Yeah. Okay. So, okay, so basically, hi, my talk is going to be entitled From Close Source to Open, so how we learn to live and mostly love Git. So why this title? Well, I guess the next slide might explain why. So my name's Jason, I work at Microsoft. So I've been a software engineer on the Azure App Platform for eight years today, actually. Yeah, whoa, okay, there we go. So the reason why I'm actually super scared to come in front of you guys to talk is because Microsoft used to be all about this, right? Windows, Windows and Windows and maybe some .NET and like Microsoft stomped on competition and was just like open source while, you know, gesture that you can't see, right? So essentially, I had at one point talked to a bunch of university students and before they knew that I was actually a Microsoft person recruiting them, you're like, oh, from the source, boo, and the minute I was like, by the way, if you have a resume, please hand it to me. You're like, Microsoft, yay, please, come. So it was a really weird sort of diametric thing because when I was in university, I also found Microsoft kind of almost repulsive. I put Linux on my laptop and all the other stuff that people like to do. And so hopefully in the eight years that I've been in Microsoft, well, my observation is that things have changed. So this is the new world that we're in right now. We're in this environment where we're using Visual Studio to basically develop for everything. While there's icons that say Windows, Windows, yeah, still more Windows machines than anything else, but there's a Mac machine, there's an Android, there's an iPad there. Servers can be server agnostic. So this is what Microsoft is now focusing on nowadays, right? Instead of being closed source and we don't care about the open source world, this is the new world that we live in, like open source kind of is important. And what ended up happening was that because there's an all up Microsoft initiative, the app platform had to change as well. And so we did this thing called .NET Core. So previously this one, the one over there, .NET Framework 4.6 and 4 and 2 and 3, etc. All closed source stuff. In fact, the really funny thing was that we had this guy who would still work for Microsoft, but back in the day when .NET 1.0 was closed source, the license agreement said something along the lines of, well, if you tried to decompile this code, you're going to break the terms of this license agreement. So what happened? Because Microsoft was also famously siloed at the time, someone internally couldn't get the code to actually do development. And so what happened was that some guy externally, he wrote a tool to decompile .NET, Microsoft didn't go and try to prosecute him or anything like that because that would be bad PR. And then we eventually hired that guy to work for Microsoft because, well, that was the most expedient thing to do. And it turned out that, I was just talking to a friend about this, it turned out that probably 75% of Microsoft was using this tool that was supposedly illegal. So what do you do about that? So anyway, what we've done now is we've moved a lot of this stuff into open source. So this .NET core thing is this new fangled open source thing that we envision runs on all those servers, runs on all your platforms, et cetera, right? And we thought our timeline would be something like this, right? We kick off, we port the code from one place to the other, and we just do some minor cleanup, you know, change an outking stack for your Mac or for Linux. We go open source, we have a gigantic ship party like Microsoft always does. People start loving us again, then we profit, whatever that means in the open source world. You know, that was the grand plan. We started on this probably sometime in like 2013 was when my team started going on to this. And the timeline turned out to be a little bit more like this. So we kicked off, we reported our code and we couldn't compile it. We did some supposedly minor cleanup, we built it, and then we were like, oh, there's a mandate to learn Git, let's learn Git. Then it's like, oh crap, things didn't work. Oh my gosh, oh my gosh, what's that? We tried to fix stuff, it didn't work. We tried to fix other stuff, it didn't work. We made a whole bunch of assumptions internally. That didn't work either. And so we encountered a lot of issues that we never anticipated because of assumptions that we had made, for example, on internal things, right? We've been used to working on closed source for ages and ages and ages. So it didn't occur to us that, hey, when we go open source and we want you to test a client versus a server, well, we didn't have any internal service to test against because we couldn't access the servers nor anybody else who clones the repo wouldn't have access to the server that we're using to test. So that was kind of all these little things that we had always taken for granted. We just didn't think about it. And as we started learning through the process, going from the closed source world to open, we started learning a lot of these things. So in fact, what ended up happening for this particular case was that we ended up having a bunch of toy repos inside. We paid GitHub and we said, look, we need some private repos and then we started playing with them. The process was long, arduous. Git was actually surprisingly hard to learn because we didn't have a community like this. Well, not that I could find one anyway in Seattle. So we toyed around for an awful long time trying to figure out how to use Git, like what was the best practice. All sorts of other stuff, like we made the mistake, like we pushed in an access key, realized that we couldn't obliterate the history like we used to be able to in TFS. We pushed in references to internal servers that we couldn't actually access anymore. We migrated to Jenkins. Jenkins had a bunch of assumptions that we weren't aware of either as we were starting to push things through. And there were, I don't know how to put it, there's just weird issues every so often that we couldn't figure out. For example, we assumed that all Windows environments had like Kerberos authentication. The equivalent of doing this in Linux and Mac was a lot harder and we needed to use IPsector to go from client to the server that didn't work, et cetera, et cetera. So this timeline is still to be continued because I'm still working on this. It's consuming all of my time right now at work. And frankly, it's crazy to figure out what I've learned in the past year. But most importantly was how we ended up changing from a closed-source system into Git, which is mainly what I'm here for. So we've been used to using TFS for version control, which is very centralized. And it was a very challenging task for us because we, especially for those of us that have used traditional version control systems, going to distributed, there's all these concepts that like committing or pushing, fetching, branching, merging, all these things have the same words, but they mean absolutely different things. So as an example, when I was helping my team on board on to Git, what ended up happening was that one of my other developers was just like, all right, I committed all this stuff. Why isn't it showing up? And I said, I don't know what, this is me over the phone, right? And so I'm not sure, but I really want to see your code blah, blah, blah, and finally I said, let me remote into this, let's figure out what's happening. It turns out that he didn't push, right? Simple little things that we didn't figure out. There's a command called undo in TFS, which undoes a change set, undoes a version from one version to a previous one, except in Git it does something entirely different, which I forget, and I've just never used it so I don't get confused. The concept of having an entire file system be, oh, even checking out was kind of weird because we were like, how do you check out? There's no check out. And no matter what we did in terms of educating people about this, you ended up having a case where people just didn't get it yet, right? The whole concept of checking out, it's been ingrained into us where you edit a file, you go check it out. Maybe TFS does it for you or maybe Visual Studio does it for you, but we've always checked out. And now suddenly when you can make a change in the file system, it gets confusing, right? We actually made an assumption, too, in some of our build system files that things needed to be checked out or couldn't be checked out and setting read attributes and stuff like that, and depending on that, well, that blew up in our faces pretty bad, too, as an example when we moved from TFS to Git. We also discovered that there's a lot of weird Linux-isms, right? So we're at Microsoft, yes, we have Macs in-house, but it's for the people that develop Office for iPad or the secret special people that are locked away in a building that we never get to see. But we have Macs in the environment, but generally, this computer being my baby for the past three years, it's a Windows machine, so using Git on Windows is reasonably easy, but not as easy as it could be. I alternate between PoshGit and Git Bash and just using the command line, PowerShell and like, oh, all these tools got me, and just simple little things, like using a four snatchers of the backslash, like the normal command line will sometimes puke on it, and sometimes it won't, right? So we actually wrote a tool to, like, as a plug-in to NotePad++ that changed everything from backslash to slash or vice versa. Little things like that, we also couldn't figure out what head was for a long time until actually I came to the Git 0.10 Meetup, and I said, okay, guys, what the heck? What is this? Help me understand this, right? And so this community had just literally, you know, saved my life in terms of allowing me to understand Git so I could explain it to other people. Things like how to make a good commit message, previous, well, here's an interesting example. Because we're open, we're open source now, everything's open, and we have to be kind of careful about our language, right? Previously, if we were committed something or checked in something and it was bad, we ran this tool called PolyCheck that ran through, well, we still do this, but we basically go through like, I think 30 different languages looking for your swear words, your bad phrases, your, like, sexual references, and like all these other things that are bad words, but we had time to figure this out, right? So the running joke inside is that if you want to learn no language, you go to this tool and then you like, grab the word list, it explains to you exactly why this word is bad in any language you want. So, you know, so we ran through these tools, we had time to bake it, but in the open source world, you go get pushed and you're screwed, like, there's no way to really revert back a message, well, yes, kind of, but you don't really want to. So just little things like this were huge teething pains for us. So what did we end up doing? So Microsoft has its own tools and it's a gigantic tool called TFS. So nowadays, instead of using TFS, we use GitHub, Jenkins, XUnit, Coveralls, Nougat, Gitter, Chocolatey for Dev Machine setup, we have some Windows tools, SourceTree, PoshGit, so we're using basically as many tools as we can find outside for support, basically, and to, you know, to put our experience as close to our open communities' experience as much as possible. We also ran into this really interesting case where we used Jenkins as a CI, we used .NET bot as our user for triggering things and sending messages to users. Initially, it's kind of a weird thing, because if you think about it, having someone be able to run CI is kind of dangerous because they can essentially execute arbitrary code anywhere on our CI system, right? So we decided to lock it down and we said, unless you're whitelisted, we need to check through the code first, turned out the community hated us for that, absolutely hated it. And because it was a time delay, it was just a hurdle to development. So we turned that off. So anybody in this room, you can commit something to our repos and it will get run. Please don't do it. Otherwise, you know, it brings down our CI machines and things get really slow and bad. Of course, Microsoft being Microsoft, there's lawyers. So we actually had to create our own tools to make people sign license agreements. This CLA bot allows us to sign, use DocuSign to sign license agreements. So I'm contributing to Microsoft code. Yes, I'm allowed to and I agree that this will now be MIT license, etc., sign it, push it, and it just works now. So we had to write a bunch of our own tools as well. With Git, as I mentioned, there's a higher learning curve. There's many different ways to accomplish the same thing. All of them being right and everyone being religiously attached to one or the other. So rebase versus merges, squashes versus rebases, etc., and we were actually fearful to begin with about screwing things up, because we didn't know about Reflog, for example, right? And one of the best things that we could do was have a Git guru, as it were, turn out it was me because I was attending, turn out it was me because of you guys. I figured out how to use a lot of Git because I was talking to a lot of you. So thank you for that. And so finally we went open. We got our first pull request and in came the trolls. So this was our first pull request. Looks very innocuous, except my product is called WCF. This guy had gone ahead through our repo, did a search, changed all WCS into WTFs. So we have to get a new sense of humor. So this is our response. Nice. WTF is a bit overloaded as an acronym around the web services space. That was the best we could come up with. And this guy, literally, he managed to get a pull request within like 10 minutes of us going public. Everyone's monitoring everything. But really, it's worth it. I mean, we're open source now. It's been a great learning experience. We can now run on Windows, the .NET framework runs on Windows, Linux, Mac. Still working on it. How am I doing for time? I have like two or three more slides. Okay. What I missed from TFS, shell sets, they're just server based diffs. I really hate pushing around patches and diffs and everything like that to people. If I want code to like not be shown yet, TFS bug tracking, good, GitHub does it well as well. Again, it's very personal preference based, I think. And we use this thing called code flow internally. You can go and bing it. It's not a public tool, unfortunately, but we basically end up, it basically looks like how VS does code reviews. We do like maybe 30, 40 file commits at one time sometimes. Yes, I know we should split it, shoot me, but realistically, sometimes that's what happens to bring up a new feature and the GitHub tools just aren't that great for it. So just to summarize, from Close Work to Open was a huge shift in how we worked. We're now using GitHub and GitRAM to communicate with everyone rather than internally emailing each other. We create issues as soon as we can. We work in the open, public feature branches enforce wherever we can. We have to learn how to make good commit messages. We now do design discussions for .NET online via Hangouts or Skype depending on the technology of the minute or who the person prefers. The biggest, most important thing is everyone is learning from and contributing to the community again. This is one of the things that I really, really like about open sourced, open sourcing things is that now we're contributing back to community. We're giving and we're also getting. And finally, yes, Git community, you guys are great, seriously. We're learning all the time. I'm learning all the time. In fact, we have a post right now called how to train your dragon where essentially everyone is piling on about, hey, you guys need to do this. You guys should do this. You guys should do this, right? And so for me, I'm about a year into learning open source and stuff like that. There's plenty for me to do. As Microsoft did, we've been open source for maybe three, four years, but still learning. So any feedback, please provide it through GitHub, et cetera, et cetera. And I think that's it for now. Thank you for having me. I know I'm a bit over time, so I'll give you back your last one now then. Any questions? Yes. So what was the biggest challenge that you see you're moving a huge amount of code from TFIs to Git? I mean the huge challenge was actually scrubbing it and making sure that it was sane to go out the door realistically. All this stuff that we had assumed closed source and you can only decompile, we're now at a point where we had to scrub it and make sure that things were okay. And then because we also changed platforms in the meantime, a lot of things that we assumed were Windows only, the assumptions are false now, right? So you discover very quickly that you've taken a lot of assumptions that you're just unconscious and at some point when you go out, you're like, ah, crap, that's what it was, right? So that was the biggest thing that I took away from this is that I have a lot of assumptions that I've built up working over the years and this is something that we, you need to change. It's just the bias that I've always had. Yes. Do you have any problems with casing of folder names and stuff? Sync of folder names? Yeah. Oh, casing. Yeah. Because, of course, Windows might have that sense of casing and then if we are working with other developers, we're in the next step. So the question was about casing of file names and stuff. We haven't run into this yet, hopefully we will never. One more question. Is it okay? Yes. Are you guys still using Jenkins for your build? Yes. We are still using Jenkins for our build. How long does it run? How long does it run? It depends on the project. For the core FX project that we're running, it takes about like 30, 40 minutes, I think, because we're doing a Windows build, a Linux build and not a Mac build yet, but we're doing two builds and we basically have two sets of tests. One set of tests is what we call inner loop that's supposed to complete fairly quickly for as soon as you do a pull request, then it'll run a very basic validation that's probably about like five minutes. The outer loop test which runs on a schedule and validates the entire code base and does all of our tests, that's like probably the 40-odd minutes that I was talking about. Okay. Thank you.