 And I'm going to show you your user. And this should not matter. And it's AMP's mission to make it not matter. We're going to talk about this morning about freedom. We want to be free from being stuck on one version control system or only going to easily use one version control system. AMP wants to be a familiar, customizable interface to every version control system. I'm going to describe what AMP is, why AMP matters, what AMP will do for you, how you use it, and how you can help. So my own version control journey, when I went to college, there was no concept of version control. We kind of did our little projects. Did anybody actually get introduced to version control in school or education? OK, there's one, that's two, that's some progress. When I went off and actually got a job, then I was introduced to VisualSrsafe. Any VisualSrsafe passed, hopefully, users out there? Yep. So it was a small company. So it was pretty much lock the entire project, check in once a day, and hey, it's a backup, right? So I eventually started reading about other systems and things. And I moved that company over to Subversion to get things going a little bit better. I'd heard about distributed version control at this point, but it was a conservative company, small teams. I was up with a centralized system in Agui to kind of help everybody through that transition. But over time, I was starting to kind of wake up from being just an employee and said, OK, I need something for my own projects. So OK, now I want to investigate distributed version control. I'm not under the same constraints anymore. Now, I narrowed my field down to Git and Mercurial at that time. And then keep in mind, this was 2007. I was making this choice. Some things have changed since then. Everything I read said that Git had this really arcane kind of command set, whereas Mercurial was a lot cleaner. Using Subversion, I also got used to the Subversion online book, which was a very useful introductory reference. And there was a version of that for Mercurial, which later became an actual printed book. I was not aware of anything that kind of had that same level of tutorial quality for Git then. The company I was working for, also, we had primarily Windows machines. I didn't want to cut anybody off. Git's Windows story was still kind of shaky at that point. You could kind of sort of get it to work under SIGWIN, but it still wasn't quite all there yet. So at that time, in 2007, I made my choice on Mercurial and eventually moved that company over to that. That was 2007. In 2008, GitHub came along, and Ruby and a lot of other communities kind of went over that way. Since then, I've certainly used Git, branching, rebasing, all that fun stuff, although a lot of my repositories are still in Mercurial. So that is where I'm coming from if anyone wants to try and evaluate any biases I may have. There's my reminder. All right, so what is AMP? AMP is a familiar, customizable interface to every version controller repository, or it's trying to be. It wants to give you your familiar interface to your version control through a common API to every repository that you might want to access without having to learn its new conventions and things. Now while its goal is to be an interface to every version control repository, what you'll get if you install it right now is full Mercurial support. And I'll explain why it's that instead of Git as we move along here. But that's where I started from. So it also wants to be familiar and customizable. So it has a flexible command system with commands that are written in Ruby. So you have the complete power of a general purpose language available to write custom commands and extensions and things. AMP was written by Michael Edgar and Erie Brown, operating under Kibarnica. And Michael actually rearranged his schedule to come down here to RubyCon today. So I'm certainly glad to be meeting up with him. So the name AMP is a little bit of a play on Rails, which apparently is a slang term for cocaine, which DHS was even talking about earlier today, which puts a whole new spin on Ruby on Rails. So going to some features of local nearby towns, they decided to make AMP a play on meth. Even though it's not an obviously drug-related thing, but it's a short term that kind of followed along from that precedent set by Rails there. So they had the problem of who wants to make this general purpose version control system. And how do you do that? How would you make a version control system? And seriously, where would you start? Anybody? Now, where you'd start? Yep, yep, read the other ones. So when they started this project, they said, OK, we're going to start with the material implementation. Essentially, clone that into Ruby, and then we'll refactor and whatnot from there. This gave them an existing implementation in a dynamic language. It wasn't as big a leap as going from something that was written in C or some other language. So it could translate more or less without as much a conceptual conflict or dissonance there. One of the things that happened because of that is that since Mercurial was GPL, AMP as a derived implementation of that necessarily became GPL, even though they might have preferred a more open license like the Ruby license or MIT or something like that. So it actually essentially completed that conversion. They got complete implementation of the Mercurial API as something we can start testing and playing around with and building upon for the other systems. So what I've just described is AMP 053, which was done under the title of John Locke. And I'll be using that name to refer to that version of AMP as we go through this presentation. And that sort of icon will signify I'm talking about what you'll gem install today. I heard about AMP a while ago, and I didn't really get into it right away just because of timing and things. But I finally had time to do that. So I went and I found the AMP web page, said, OK, there's lots of information here. I've got examples. I've got a little bit of explanation of how things work. I've got pointers to the code repository. Things have been recently updated, so the project is definitely still alive. We're starting to see the Git support coming in, so this is a good thing. I know that'll help the Ruby adoption a lot. But as time went on, I went and I got back into it. So I went in, found some tests that needed some help, some things that weren't working, made some patches. Things were all looking good. So I went ahead and threw off my second proposal, a Ruby con. And then things got a little more interesting. As time went on, I checked back, did some more patches and things. The main repository still hadn't been updated. And the AMP web page disappeared. And as you can probably guess by the fact that I'm here now, the proposal got accepted. And it's like, well, that's interesting. I hope I'm not doing a funeral speech. No, the repository still hadn't been updated. So I said, OK. I remember there was this out of date mirror on GitHub, so maybe they actually switched over to there. And well, no, there were no updates there either. But hey, what's the SAMP Redux thing? So there's something going on here. So this is where I finally emailed Mike and Erin and said, hey, what's going on? And in fact, they had been doing some internships and other distractions. They had a cheap web host. So that was something that it's taken care of. And one of the things I found out is that, yes, they had started to do the git implementation, and then things got a little bit more interesting. It turned out to be a little bit trickier than it first expected. And this isn't really all that surprising considering that they started with essentially a clone of the Mercurial source. Git does not have as close of an overlap with that set of concepts. And in particular, what this started to point out is that Mercurial was very tied in with its concept of what files are stored where and how they are stored. It didn't present quite the higher level interface to version control that they wanted to present in order to easily cover everything. So taking this together with the licensing issues, I said, OK, it's time to start this thing over. We've learned a lot from it. And now, taking together what they learned from doing John Locke together with other experience, it's time to take that and taking a lot of that code, but restructuring it into a new system. And this is part of the mission of AMP, to learn how to build large Ruby systems, and as well as learning how to build version control systems. So maybe it'll take a few iterations. As much as it might have been nice to plan for this, at least it's nice to have that milestone out of the way. So this brings us to AMP Redux. And the less you think I'm trying to mislead you by talking about two versus the vamp, I will be attempting to clearly identify John Locke, which you can install today, from AMP Redux, which is coming along nicely, but is still kind of in a period of major reorganizing right now. So as I said, Mike and Ari, we're off doing internships and things. They're learning a lot about software engineering and pulling that into how the new design of AMP. They're separating, making a better separation of interface from implementation, so we don't have that same sort of tied-into mercurial or what-have-you. There's a higher level interface, and then below that you'll have the parts that deal with the messy bits. AMP Redux will be a more modular system. The primary modules at this point are AMP Front, which is sort of a general command line shell that will be a plug-in host for the rest of it. AMP Core will turn it into a version control system and have these sort of general support libraries and things. And then you'll have all of the repository formats and eventually command sets for that. So AMP is trying to be a familiar, customizable interface to every version control repository. Here's my reminder again. Excuse me. All right. So why does AMP matter? Well, I imagine that most of you, thanks to GitHub, are using Git. Git is written in C. Git's arch-rival mercurial is written in Ruby's arch-rival Python, as is bizarre. There's a system called Dark's written as perhaps slightly more palatable Haskell. There's a monotone, one of the original distributed systems in C++. The big gorilla subversion is written in C. There's a distributed version of that called SVK that's written in Perl. And if you add all these up, there's something missing here. In fact, if you go to, for instance, Wikipedia's comparison of revision control software and do a search for Ruby, you're not going to find a whole lot. Apparently, nobody thinks that Ruby is a viable system for a mission control piece of software like a version control system. And one of AMP's missions is to prove that it is viable for large-scale applications. So AMP is trying to become a familiar, customizable interface to every version control repository. And despite its goals, someone will inevitably ask, do we really need another version control system? I mean, really? Well, at times, I'm sure people have asked, do we really need another implementation of Ruby? I mean, come on. We've got MRI. Isn't that good enough? And yet, some people said we want one in Java. Some people said they wanted one in small talk, but those guys are next door. Some people said, we think that writing things in Ruby is a really nice way to get into our software systems and make them easily modified and understandable. I suppose that's where I should thank the Ruby Con for moderators for not putting the opposite of Ruby Con, or Rubinius. Ruby also made its fame through Rails. And yet, that wasn't good enough. We said, well, we'd kind of like a interface through Sinatra, or maybe we're going to do Merb, which also went back and informed Rails 3. And last night, I heard about this thing called Fog, because apparently, some people like being able to access more than one Cloud host. I mean, isn't one good enough? But 700 people think this is an interesting project. It's interesting. So AMP wants to be a familiar, customizable, interface to every version control repository. I talked about how my journey went from visual source space to subversion to Mercurio, and I've used some Git. Your journey may look a little bit different. How many people here have only used one version control system? OK. Two? OK. Three? More than three? Yep. The point here is these things change over time. There will be a next thing. And I believe that having a common API that will let you kind of access and have these similar interface to all of these different systems will put you in a better position to adapt when that next thing comes. And if you're still not convinced, all I can say is thank you. So how will AMP help you? Its aim is to be a familiar, customizable, interface to every version control repository. You can use it now to access Mercurio repos and eventually other things without necessarily having to install Python. You get both the AMP command that works essentially like the HG command, and you also get a library you can include into your Ruby code in order to programmatically access Mercurio repositories. And as AMP matures and rebuilds AMP Redux, eventually other repositories. At a more abstract level, what we have right now are version control systems that act like silos. You're pretty much talking from its command set to its repository. You'll usually get one-way imports, but this has to be redone for every new version control system to every other version control system that's already out there. You occasionally get two-way interaction like HTGit or GitSBN. The problem is this kind of has to be done for every pair. It's an n squared problem, which means this is why you don't see a lot of these things, because it'd be a pain in the butt to generate every possible combination. AMP is trying to turn this into an n plus n problem, where you define your repositories, and then you have your workflows or your ways of interfacing with those, and these become separate problems. One of the nice things that, for instance, Active Record did is it made at least all SQL-type databases look more or less the same to your code. You don't have to worry about all the little differences. Fog is doing something similar. It's giving a common Ruby interface to all of the different cloud hosting providers, so you can just say provision something and not worry about the details. AMP wants to give you the same thing for version control. It lets you take, if you're familiar with Git, use your Git commands, and it will let you talk to any database that's out there, or repository. And you can say that, OK, I'm happy with Git. And for your own projects, that's great. But what if you want to contribute to Firefox? That's a mercurial repository. The same thing for Addium, the same thing for Vim. Inkscape is in subversion. That's another system you might have to learn. Or in your own system, you've got your comfortable tools, you've got your custom commands, extensions, maybe you've got a history visualizer. If you move to a different repository, you've got to go find all those tools again. So part of AMP's mission is to let you customize how you interact with all of these repositories. Use your command set, be that Git or a customized version of that, or a completely customized workflow eventually. On the other side, if you have a project that's in a Git repository, other people, no matter what their experience with version control systems is, what their workflow is, they can contribute to that with having the added barrier of learning a new command set or repository format. This also opens up doing kind of a mix and match. Choose the command set you like, and the repository format you want based on performance or size, or whatever else you want to optimize for. So it wants to give you your familiar customizable interface to every repository format. Another thing that is interesting is that, principally at Rails 3, it's a highly modular system. And going from Rails 2 to Rails 3 and through all of this history, they've allowed you to get into more switching out your ORM, your templating engine, all of these different pieces. AMP is also trying to get that kind of modular system where you can exchange things out. So it actually opens up to easily exchanging things. So if you want to experiment with a new kind of workflow that doesn't exist, you don't have to create a repository format. You can swap out just that one piece. Back in the day, they had to rewrite Merv, essentially because they couldn't change out pieces of Rails at one at a time. Now with Rails 3, you can change out those pieces. So we have common API. We can start switching things out like that. So you can change workflows. You can experiment with new repositories that may be optimized for some new feature or frequency of updating or something without having to go create a command line system. It also wants to make extensions that will work with anything, essentially. So every version control repository has these extensions, and a lot of times they'll get the same extension or re-implemented. So every version control system has to re-implement all these extensions. Every extension has to be re-implemented for every version control system that somebody wants to use it for. AMP gives you a common API so you can rewrite these things one more time, and then you're done. They work for everything. So how do you use AMP? Well, for John Locke, which accesses material repositories, you can just gem-install it now and use it with the command line, just like you would do with HTTP or require AMP and use it in your code. One of the missions of AMP is to make highly customizable commands. As I said, it's a familiar customizable interface to every version control repository. So whereas most version control interfaces will give you key value pairs for default options and things, AMP gives you an AMP file, which is a Ruby code. So you have the full power of Ruby you're disposable to create custom commands and tweak settings and things. This is done through a system of open commands that are going to try and work like Ruby's classes. So if they are open, so the same syntax used to create a command is what you use to open it and edit it. All right. Now things get fun. There we go. All right, all right, pretty good. All right, yep, over just a little bit. All right. So I've got my AMP file in a query repository currently. So I'm going to, come on, and you always get nervous on your own stage. So hopefully I won't get too many typos here. So I'm going to open up my log command. Actually, I suppose I should do first all the fun things you forget when you're on stage. So right now if I do AMP log, I got a whole bunch of stuff. I usually like a shorter command. So I'm going to change the default of the limit option to something else. So I only get three, and of course I can still use my options to override that just like normal. So that's a very basic, this is still kind of the key value thing like you can do with anything. But the nice thing about this is that these commands are Ruby. So I happen to be in the, actually it's sort of my own version of Johnlock edge. So I am going to actually search for the AMP command. So there's mine. There is the actual AMP command for log. It is written in pure Ruby the same style you would use to create your custom commands. So if you want to see how something works, you just go look it up and see how it works, copy it. So real quick here, we've got our opening command log, just like I did for modifying it. It's assigned to a workflow. This is so you could easily switch between the get workflow, ht workflow, subversion workflow, et cetera. I should warn you that this is currently being put on the back burner for AMP Redux just to kind of focus on getting your repository stuff working. But we'll have flexible commands. So let's be pretty easy to put back. We get a description. This is what goes into the AMP help so that you get automatic help. And along with that, you get all of your options. So these are just options. These are declared with each follow up library that's included into AMP. You might be familiar with that from some other projects that use it. This also has descriptions which get put into the help. So if we do, there we go again, butterfingering things. So all of this essentially gets you automatic help. So when you're at the command line, you just say AMP help and you'll get an up to date help pulled directly from these option commands and description and things. So your custom commands will essentially get help for free once you declare your options. Let's see. OK. Then you get a block that defines how this thing runs. Is that it? All right. So you got your block. You get a bit here that this is essentially, this is almost boilerplate, just pulling out your options in these convenience variables. We do a little bit more tweaking our values and customizing things, filling in default, stuff like that. And from there, I mean, this is just ordinary Ruby iteration going over our repository. We've got our repository object just indexed by the revision you want. So this is just plain old Ruby code to pull this out. Then we've got a helper method that's built into AMP here. This is essentially taking all our change sets and running them through an ERB template. So if you've used Rails and things, you probably already know how to use this. So that is the log command. And what I'm going to do, if I remember how to do this right, is I'm going to grab that. And I'm going to come down here. And I'm going to make a custom command. And I'm going to use this in my template because I've got a let code there iterating over revisions. That's just what we need. Now I had a situation a while ago where somebody asked me to give a quote on something where I had done something similar recently, but I hadn't really been taking time for it. So I wanted a command to give me a quick summary of how long I spent doing that. So I'm going to have a custom command. I'm not going to send it for workflow. It's pretty much for everything. It's going to have a description, estimate time spent. I don't need that option. I want to limit on it. I don't need that. I don't need that. I'm going to kind of need that stuff. I'm going to do my iteration a little bit different. All right, so there's our basics. I want to use some different words here because these are the words we're doing a down to count. So I don't really like that version of, so I want to start, I want to say that's my last revision. And instead of stop, I want to say that's my first. All right, so anyway, that's just some cleanup. Actually, I'm getting ahead of myself. Because if I do, let's see, amp help, commands. That's kind of a big output. It's already in amp, if you do amp list of commands, just doing that, actually just the command billing, puts it in the amp's list of commands. If I do amp help billing, I've already got the basic description and all of the options available to me just for declaring that. So now, one of the things I pulled in essentially built into amp because it's a virtual control system is the repository object. So there, I've already got a Ruby object I can use to manipulate this with. Now what I'm particularly interested in is the particular set of change sets. And that's a lot of them. I should probably put a limit on that. Let's sort of pretend. That's a little bit more manageable. And that is the option parsing essentially giving you those two fields to put on there. Now what I actually want in this case is not change sets, but dates. So let's see, I don't want to do this. I want to map that over change sets. And I want it, not change set, not change sets. I want the, say, date. And here we went into one of the things that inherited from Mercurio, which I'm not with the plan on this is for amp redux. I would think, hopefully, cleaning this up a little bit. So Mercurio, rather, stored its dates as a time stamp and a time zone, which is not necessarily the most convenient thing you want. For the sake of speed here, I'm going to cheat and say I've already looked up that what, in fact, we want here is what John Locke called easy date, which actually gives you something, well, it's not easy to see there. If we change that to, see that a little bit easier. And these are, in fact, time objects, so we can subtract them and do all that fun stuff with them. So that is our date. Now what we actually want here is a difference between two dates. So I'm going to use a fun little Ruby method to give me pairs of things from this array. And so now I'm going to be taking pairs of things. So we've got our before and our after. And it's going to be easier to rewrite that. So what we have is you're going to want after dot easy date minus before dot easy date. So that gives me a bunch of time differences, although there's some pretty big numbers in there. So I think what we actually got here is seconds. Actually, yeah, that'll work. So what in fact we want here is hours. And no, that's not built in. I'm going to define it. So ours can take our seconds, turn that to seconds to minutes and then to hours. So that's a little bit more reasonable, although it's kind of ugly with all those decimal points on there. So I'm going to want to format this a little bit nicer. All right, so that's a little bit easier to see. But I'm not given the huge coding marathon, so I don't think I was working on this for 71 hours. I was probably doing it sleeping or something during that time. So this is where we actually get into a little bit of heuristics. What in fact what we want here is billable hours. So I'm going to go up here and I'm going to define a quick helper. And I'm just going to say, if ours is greater than 1, I'm just going to call it 0.25. Else I'm going to say it was the whole thing. So now I've got some more reasonable times to work with. And at this point, we can actually start thinking about summing this up a little bit. So I'm going to grab this as a list of times for easier reference now. All right. And actually, I want to want this to be my hours, not strings. So there's my array of raw times. So now we just want to take, actually, what I learned just today is you can be using reduce for this. I want to reduce, you know, this isn't the fastest way. So there's my time. And final touch is going to be make that puts and format. So that is a quick and dirty, usable command in, I was probably like 10 minutes, even though I kind of was going to save myself some research. I just looked up the AMP source, found something that is similar to what I wanted, and then started modifying it from there. All right. So I believe that is all of that sample. Oops, I actually wanted to skip my slides now. So AMP is a familiar and completely customizable in Ruby interface to every version control system. Well, at least it's trying to be. We've only got McHurriel now. How can you help out AMP? Well, one of the goals of AMP is to be an example of good documentation and hopefully generally good Ruby project. I was actually very impressed with the amount of effort that Mike and Ari had put into setting up their project so it would be easy to understand what's going on and how to get into it. They developed a manifesto, which actually set up the explicit goals for the project, which I've been quoting throughout this presentation. There's also a style guide in a very old testament style laying out what they expect to be in their project. And a to-do list so that new contributors have a lot of places where they can say, OK, here's where I can jump in you at a couple different levels of complexity and scope. So you have something to jump into. As I said, they're kind of refactoring into AMP Redux right now. It's going to be a modular system. The first and probably most advanced, or furthest advanced part is AMP Front. It's actually pretty far along now. That handles the command set, which includes all the option parsing through Trollup, which is also kind of feeding off that for some of the built-in help features. One of the interesting things that's going on here is that whereas in AMP John Locke, commands were instances of a command class. In AMP Redux, the commands are actually classes. So the plan is this will hopefully allow us to take advantage of Ruby class modularity mix-ins and things in order to make it easy to customize our commands. AMP Front is also a plug-in host. So essentially, this is the plug-in container. And then all of the rest of AMP is plug-ins for that container. First and most important of those is AMP Core. This is what actually turns AMP into a version control system. So it has sort of the generic concept of repository, general helpers like hashing and other sorts of support routines like that. Then you've got all your repositories. So you've got the mercurial plug-in, which will hopefully allow us to kind of contain that GPL code and make the rest of it able to be easily reused elsewhere. And then, of course, we're pushing forward on AMP Git, which has lots of interesting possibilities. I'm kind of wondering if there might be some room for diversification here, kind of having multiple backends. You could, for instance, try to do a command line wrapper around it. But it turns out they actually tried this. And Git is just really inconsistent in how it prints out its reports and things, which makes it a real pain in the butt. There's Git, of course, which is an interesting possibility. They've got some Ruby code. They're still shelling out. But they're doing a lot of the hard work for us. What AMP had started working on in the sort of edge John Locke is, was a pure Ruby implementation. And also, they want to have pure Ruby because then AMP runs everywhere Ruby runs. We don't necessarily have the portability concerns, like some of the earlier versions of Git had. And today, I learned about a project called Ribbit, which is wrapping something called LibGit2, which is sort of a library-oriented re-implementation of Git in C, so it'll still have full speed. And the Ribbit is a Ruby wrapper around that. So this will be a very interesting avenue for us to poke at. And for the review, I'm good. All right. So in review, AMP is a familiar, customizable interface to every version control system. If you want to access mature repositories, you can install it now. And you've got command line and a gem you can require and using your code. Its goal is to be free from devotion to a single version control system, to allow you to use anyone and allow everyone to use every repository, to allow you to pick how the interface you want to your repositories and to other repositories, to have extensions that you can use any extension on any repository, and write extensions that work on any repository, to have easily customized commands in the Ruby that you already know, to prove that Ruby is viable for large-scale applications, and to discover how to build large-scale applications in Ruby, and to be an example of a well-run project with good documentation. So AMP is a familiar, customizable interface to every version control repository. These are our goals. These are our tools. Now is the time. And you could help make it happen. So I'm Justin Love. Michael Edgar is right down there. Can you ask me any questions? And I'm sure if I can't answer them, he probably can. Are there any questions? John Locke was on BitBucket. I think we're pretty much primarily on GitHub for Redux, right? And everything's on GitHub now. There's your past story for everything coming. It's under just a month. The primary is under Michael Edgar is the title. I mean, if you search for AMP, you'll probably turn up one of our repositories at least. Let's see. The structure is AMP Redux is going to be eventually become AMP. So you gem-installed AMP, and it'll pull down the rest of it. And it'll pull AMP front, AMP core, AMP get, et cetera, as all the pieces. Yeah, you're building a new server for that, is that correct? OK, so the web page will be updated shortly. It's still referred to John Locke only at the moment, unfortunately. But that's coming. Anything else? All right, thank you very much.