 All right. I'm here to talk about testing queries. We talked about queries a little bit when Kyle was talking about MongoDB and he reminded us about indexing. That's true. Even with the brand spanking new MongoDB, it's new. It's different. It's schema-free, but you have to watch your indexes just like you do on relational databases. And so the number one rule of relational databases is still true. It's never doing an index read. You might be thinking, huh, everybody knows that. But actually, I heard a speech by someone from New Relic the other day and he said the number one mistake that they find in their monitoring is missing indexes. So obviously, everybody doesn't know this or they're not implementing it well enough. So I have a little decision tree about when to decide whether you need an index. First, will a customer ever be waiting for a result of the query? No. Well, okay. Maybe you don't need an index. Yes. Well, how many documents are in the collection or how many records are in the table? If there's one, you don't need an index. If there's more than one, never do an unindexed read. So we know this and we do this, but not as well as we ought to because how can you be sure that you have a good index on your query? Not just any index, but a good efficient index. And the normal way you do it is you have a big review and analysis before deployment. And then you have monitoring after deployment, maybe formally with New Relic or somebody like that. Or maybe when your customers call up and scream at you because your response time is really terrible since you rolled out something with a not quite good enough index on the query. Now, when you look at those two things, what are they? Well, number one, that's big design up front. Number two, that's deploying untested code. And those are very bad things to agile developers like us, so shouldn't we be doing something else? And what we should be doing is testing the queries just like we're testing the code. And I thought about how you could write a test for a query and I thought it might be a little difficult, but actually it turned out to be really simple to do. So I published it as a gist and let me find it for you. And here is the main part of it. It's just a little unit test, a setup that makes a Mongo collection. You can do this in Mongo or any other... Oh, half. Okay. All right. You can do this in Mongo or any other database, but I implemented this one in MongoDB. And here is the test. You just set up any query and then you assert that it is at least 50. So what is this 50 and 100? That's the rating of the query. So what's this rating thing? Is that a really complicated thing? Nope. It's some very simple code that just uses the explain feature of Mongo and every other database should have something, explain or something like that. So you can just run it through this extremely simple data calculation and then you've got a test so that you can leave that in to your test suite and then if you're doing frequent deployments as long as you remember to run every query through a test like this, you will never get stuck with deploying without good index on your query. What the rating gives you is something between zero and 100 where 100 is a perfect index and zero is completely inadequate. Let's see. Can I show you one here? I'll run that code and you see the first test where is it at least as good as 50 in the rating past and then it wasn't as good as 100. It was only 99.5 in the rating. Actually, it was a very, very good index. It's a simple little table with an index on the field that we're looking up and it rated as 99.5. So you can put in to your test some reasonable level, 50, 60, something like that and work out what it's going to catch you when you do something really, really bad. So at least it's more than mediocre before you deploy it and then you'll have it in your test and never make that mistake again. It's not going to be real speedy so you wouldn't want it in your auto test test but if you put it in your test suite that runs when you check in code, that'd be a good place to put it. That's it. So has anyone used Git or GitHub in this room? Is anyone familiar with that? So sometimes you are very familiar with GitHub and then you, for whatever reason, maybe you have a repository that you set up with things that you can't put on GitHub for some reason on a dev box somewhere or you're like sitting on the airplane and you're kind of thinking, oh, I kind of wish I could just kind of quickly browse around. Well, you know what? You probably already have this program. Someone was telling me last night about GitX but I haven't installed any apps on my machine. But if you were to go into repository, and I think I have one here, and you type Git InstaWeb, it's going to tell me that I'm missing Light DPD. Now in my Linux box I just did an RPM and installed it and then it works right away. But I can say web brick and then that's it. And then, oh my gosh, look, I've got a web server and I'm running it and I can poke around the repository and I can see what's going on and it's like the simplest thing you've ever imagined and it's already on your machine. So that's it. Thank you. Git InstaWeb. All right, my name is Jimmy Zimmerman. I'm going to be talking a little bit about Ruby FS Stack Gem. It's a gem that helps you tap into the world's genealogy. So there are two things that I'm really passionate about. One is Ruby and the other is Family History. This here is my surname cloud of all my ancestors and my last nine generations. If you see any surnames up here that are yours or that you're familiar with, chances are really good that we're related somewhere along the line. Here are a couple of my ancestors, my great-grandparents. The one on the left is Marshall Felch. He actually had a dinosaur query outside of Denver. I just discovered this. One of his dinosaurs is in the Smithsonian Museum back east. The other one is Amanda Coburn and I learned that she was a Civil War nurse. One night she was in her tent. Somebody was cutting through her tent to steal her money. She pulled out a revolver, shot the guy. Really exciting stories in Family History and I'm sure all of your lives are full of stories of your ancestors. So it's all a matter of just finding those things. So I work for Family Search. Family Search is the world's largest genealogy organization. It's sponsored by the Church of Jesus Christ of Latter-day Saints. It has massive amounts of genealogy data. They're Family History centers worldwide. Thousands of volunteers ready to help you on call centers and in these Family History centers. While you're here in town, if you go do the Temple Square tour, make sure you stop by at the Family History Library and connect with your past. There's some incredible things that you can learn there at the Family History Library. So what I really want to talk about is new Family Search. It's a collaborative family tree. People can get on, add information about your ancestors. Chances are if you don't have anything connected on the system, you go back a couple generations, you're going to connect with a giant family tree and be able to go way back in time. So there's a Family Search API that connects to this family tree. We've got about 700 million person records in here. There's a rest-like web service interface on there that serves up XML, JSON, AMF, Fast Info Set. You can search the tree, you can create and read, manipulate all your credor operations on person records through this API. You can read pedigrees, so bring down big chunks of data at a time and there's lots more functionality there for you to be able to build really cool and powerful genealogy applications. We have a Family Search Developers conference coming up at April 27th here in Salt Lake. But there's a RubyFS stack gem that makes all of this stuff really easy. I find it on GitHub, Jimmy Z, RubyFS stack. It uses JSON for data serialization. I'm trying to build it to encompass all the functionality of the Family Search API with the clean interface, lots of convenience methods, and make it thoroughly tested, easy to debug. James Buck created a GEDCOM gem as well, or library that makes it really easy to ingest genealogy files as well. There's some opportunities that I see. I learned about the stories of my ancestors through Google Books. There's an API on there that if you bring the two together, there's some really powerful things that you can do. I wanted to show you a little bit of a code demo. I'm doing some things with the API. This first one is just going to be a pedigree read. I'm going to grab four generations, 16 lines of code, including the printing. Given the Wi-Fi connection, we'll see how it goes. There we have it. Okay. So essentially I just have a recursive function. I create a communicator object, hook it up with the API, give it my developer key, request a pedigree on me because I'm a signed in user. There's really powerful search capabilities here. Down at the bottom you'll see I'm calling a search function, given name Parker, looking for Parker Felch. If I run this, I'm going to get some search results with their family search IDs, search scores, gender. It also gives you family relationships and so forth. If I take that ID and do a person lookup, I can get more information on those people. So lots more things that you can do. That word cloud that I showed at the beginning was built just by a few simple scripts, throwing it through the Java API that is given that runs Wordle.net. So lots of fun things that you can do with the family search API. All right. So what I wanted to do is just basically, I learn a lot from other people about tools and things like that. And I just want to be able to share a couple of things that I have learned and I'm using that I thought other people might be interested in. I talked with some guys here at the conference, and they really weren't aware of some of the things. So I just wanted to show and see if anyone else might be interested too. First of all, I have, this is about RubyMind. I've used quite a few different IDEs. I prefer IDEs. I came from like an IDE background on Windows and everything. But so I'm not in any way affiliated with RubyMind. But basically, what is RubyMind? I know a lot of you guys have probably heard about it. Some of you might even try it out. But it's written in Java. It's the IntelliJ Java application that's just a code IDE that supports lots of languages. And it is commercial product. They have a free trial. I used the free trial sent in, used about six free trial activations through different emails until I finally decided, okay, I'm going to buy it. And it's $100. So I thought that's really not bad for a good tool. So I'm just going to show a couple of things that I really like because Ruby is a really powerful language where we get very productive in it. Rails and Sinatra and those things, they're very powerful web frameworks and they're productive. So I just wanted to show some of the things that I find productive about RubyMind. Since I'm running Linux, you know, I'm a text mate, it's not even an option. But I just wanted to show some of the things that are cool. Real quick, one thing is the Rails, there's different views of your project. The project view is the traditional, like the physical view. And then the Rails views more of like a logical view. So it groups things by I got my controllers and I had lists of all my controllers and under my controllers I have my helpers, I have my partials, I have my actions, and then under there I have my views that are associated with those actions. It just kind of groups it all together. The models, it puts all my migrations right here. That's kind of easier to group them that way than the articles. This is a model. So these right here, those are fields that are pulled from the database schema, the schema RB. This is a method. And so it'll load all those in. And then so I've got Cucumber. So it's got, it has Cucumber support, so it shows features. So it's going to quickly show some of the things it can do. Like some of the things you have to have is you have to be able to do rake tasks. So I can just say, well, what are some of the rake tasks I can do? I can say, oh, well, you know, I can just, I want to migrate, you know, so just really easily find rake tasks. If you want to just run a generator, it's alt-insert and you can just run your generators. You can run create features, models, resources, all that. Code navigation is one of the huge things I really like. I know TechSummate has some of this stuff. Like I can just say I want to type in this class name, so poster. And then it shows me all the different poster or post, you know, where it takes that string matching. Then that's class name, then there's also file name, where I can say, oh, well, I wanted to get that CSS file. And then it'll show me where all my CSS files are. Let's see, it's like there, that's my CSS file. Then it'll do, you know, you can jump out to Rails, like alt-shift-n, jump to your Rails views and such. Then what I really like is when I'm in my code, you know, we talk about documentation, how important documentation is. Well, documentation is important to me because I use my own documentation. I don't write libraries or anything that's shared. All right, it's going to be fast. So anyway, just show you, you can, like, control Q on anything to get documentation, like, so I can see, you know, what's, you know, what gosh, how, what is that call that I don't use very often. And that works on your own code that you put R dock on. And then I can hold down the control button, mix it into a hyperlink, so I can jump out to it and it jumps into the Rails code or the gems, all the gems I have associated with it, or it'll jump, you know, to my code. I can say, I can jump through relationships. So here's a stupid little demo method. So if I go back to my controller, I can show code completion. So like I see right here, I see, down here, I've got my attributes. These are from the database fields that search pollinate from, because I can never remember my fields. And so then I got my code completion right here. And then I can get my documentation all right there. There's a whole bunch more it can do. If you want to talk to me about it, I'd love to talk about it afterward. Thanks. All right. So I don't have an iPhone yet. And I realized that makes me kind of a, I don't know, a lever in this community, I guess, to some extent, because, you know, everybody's got an iPhone, everybody can do, find their location and send updates and whatever. And so I wanted to build a tool to let me tweet with my location. So what I did is I took this gem that I built that allows me to do Twitter OAuth with Snotra really easily, just a Snotra extension, and matched it up with Google Maps. So I can, like, say, tweet something. And then, see, right now the point is at where the library is. So if I wanted to, I could be like, and tweet. And hopefully that will work. You know, networking. So let's see. So basically, I set something up and I deployed it on Heroku with a free instance. So if any of you go to that, it might just completely fall over. It's a pretty simple app. I just set up my configuration. So like, with my OAuth jam, all I have to do is set a Snotra variable and then using that, like, set notation and stuff. And then with your key, your secret, et cetera. And since I was using Heroku, I set all those up as config-bearers. And then, so I turned off the login and my OAuth commit. It might blow things up. Well, so then, because the update status, reinitializes the login, grabs the longitude and updates it and says it worked or it doesn't work. I'm suspecting that that might end up being a problem. But so then, so anyway, this is just an app using this gem that I created. And what the gem allows you to do is to just require, this is Snotra app, either using classic style. So you just require Snotra dash, Twitter dash, OAuth. And that will register the extension. And then you set up your configuration. And then you can just go log in required and use the user helper to grab the Twitter user, which lets you do updates. And there's a couple of other things. I actually wrote it to do a list manager because a friend of mine was having difficulty with being able to add multiple users to a list at the same time. So it's kind of the domain objects for the Twitter users and lists are the only ones that are there. And some of the features are missing. But so find that sort of thing interesting. And also, you can also use it in a more modular fashion by creating a class that inherits from Snotra base and then registering it explicitly. That's pretty much it. So before Alistair starts, I want to make one thing abundantly clear. This man did not pay admission to the conference. And not only that, this is the second year he's done this. So I want a boo. Let's give him a boo. Now I want a thunderous cheer because this is Alistair Coburn. Very good, thank you. What he neglected to say is, you guys didn't pay me and I'm giving you information for free. So I didn't take any year-valuable information because I was home sleeping. I mean working while you were all talking. Hi-tech here, you'll notice I'm the only person here where I don't have a thing. It's just this whiteboard here. All of this is trying to get anybody here to do an experiment on an architecture that I heard. There's a guy called Greg Young. And if I put his name up here, you probably can't read it. Let's just see if this works. Twitter name at Greg Young, very easy. And he extended the thing I call a hexagonal architecture into something he calls an event, command event architecture. And there's an addition on that called CQRS. But I just want to get anybody to take a look at this. The hexagonal architecture says that the app never knows anything about the external world. What Andrew Schaefer says is, give me API or give me depth. And the idea there is if you have a person down here and they have what they think is a UI, the UI is actually an adapter that speaks into the application. And the reason you like this is because you can get rid of that and put a different adapter in which it has your unit tests and everything else. And now your app can be tested on the one side. But the hexagonal architecture says you have to do the same thing with your database. The app is not allowed to know anything about the database but goes through an adapter, which is very nice because then you could get a loopback mechanism and now you can test it. I can't get anybody to implement this stuff, but this guy Greg Young went one step further with something that was very cool. He does high volume automated stock trading systems. And he said he puts basically another hexagon around the database and he connects these two hexagons with a message queue, which he calls events, but basically there's state changes to the data store. And now he's got a perfect thing here because from the UI he sends in a queue of what he calls commands. So you have a user intention expressed as a command going into the app. You have database changes coming out of his events. He can now test this thing perfectly. It's perfectly wrapped in API. And since he's doing stock high security systems, he wants to make sure that the programmers haven't got a backdoor into the database. You can fully test this just by taking a look at the database change events coming out and make sure there are no naughty events coming out. Further, he says you can also outsource this to some other place that you, you know, India or Philippines or whatever because they have a tight spec. They have events coming out and they have data transfer objects going in, coming back out. So again, this is perfectly wrapped. So that's called a command event DTO architecture. And I just thought it was so cool but I don't get the program real systems anymore. So I wanted to come up here, put this up here, see if anybody would be willing to do it. Now I don't know if that breaks rails. That should, right, am I correct that breaks rails? Can't do that. Not at all. Rails is happy with this? Awesome. Right, now the other thing he does if you want to take it one step further, he separates the entire read side out from the right side. So he has what he calls then a CQRS architecture, command query responsibility separation. So he has architectures got an entire right side, command side over here, right? That's the command side. And an entire query side over here and he can get architectural properties on a public subscribe to this with a slow read update while he's got a stream going in here and he can optimize his architecture. So there's like three different architectures here with two stages of development. The hexagonal architecture, which is pretty easy to understand. The one I think is sexy and I would love to see anybody implement smaller big system and produce a report on what is that thing like and anybody wants to go further and do the command query separation and play that game, that would be awesome. Any takers, anybody? So you can look this up, follow Greg Young on Twitter, click on his blog, you can read about it, you can find the, you can chase the threads and find it. He doesn't say a whole lot more than this. He drew this from me on a napkin in a restaurant when we were supposed to be talking about, I don't know who knows what else, but we did that. And so that's my request. Is there any, anybody likes, do you see a problem with this or anybody willing to take it on? We've got 30 seconds left. I got it, Alastair. You got it, all right. Anybody else? One thing I can mention is Paul Diggs has this idea of synchronous race and synchronous rights. And I don't know if you saw the video and who we call, the last one we call, that it's kind of similar. I don't know if I understand it. He just drew this and I thought it was so simple and so slick, but I don't know what the drawbacks are. He uses it in high performance, high security systems. So that's like a pretty good testimony. All right, I'm done, thank you. So I'm gonna do a quick talk about something I've been working on for quite a while, using it in production at my current day job. And it's called the Bash Deployment Server Manager. So later on, someone pointed out to me that that could be used for fun and profit. So that's the logo. Oh no. No, actually it's better. EDS, hello preview, play with me. Here we go. Servers should be submissive. So that's the logo thanks to a very happy user, which I love it when they do that. Anyways, BDSM, what it is is essentially it is a Bash Deployment Server Manager. At the core, it is a framework, nothing more actually. It is essentially positioned to be a single server manager. So it would be used by say, Puppet Chef, whatever, massively distributed, proctological entity you might be using. So basically it allows for service management, so say Nginx, Pa, Apache, whatever, managing those things via something called extensions. It also manages deployments, hence the D in there. At the core, it is very modular. It is, I took all the major things I failed on with RVM and fixed them and made BDSM. So basically it is a wrapper or a CLI for all of these different extensions and as long as you follow its little framework recommendations, you're all set. So basically it's a CLI for the extensions and it allows you to manage the extensions like install, upgrade, whatever, list. So each extension has a bin directory which is basically any executable file. So this could be a bash script, a Ruby script, a Python script, compiled C code, anything you want. As long as it's executable, BDSM will automatically plug it in and allow you to call it from the BDSM CLI with any parameters you pass in afterwards, get passed right to your executable file. Templates directory, any templating system you want to use. So if you're using Ruby, maybe you want to use ERB or Hamel. If you're using bash, you use something intelligent like M4. Scripts, any scripts that you want to use for shared purposes, I use those for bashing, whatever. Config, if you have like Hamel configs or bash, maybe you've got a key value store or database store as a file, use that, version. Version file is important just for extension installations and upgrades and stuff like that. So basically by default extensions our deploy rollback and update because it assumes that you're going to be using BDSM to manage a server and something running on the server, so like a project. So deploy has a lot of hooks. I'd love to show you, not enough time. Rollback update, you get the idea similar to CrapStrono. So extensions essentially, basically it's RVM aware, clearly, I wanted it to work with RVM. So there are Rails extensions, unicorns extensions and Nginx extensions allows you to install a very simple Rails Nginx unicorn stack on a single server very quickly. There's a whole lot more extensions that are in the works in the various states of complete and I'm looking for beta testers. So meet, find me an RVM. Additionally, one minute, oh my God. Well, I guess I'll look real quick. This is the extensions directory. You can see that there's some like maintenance stuff in there like archives for downloading packages and MD5 checking things and not downloading again if you don't need to. The core BDSM directory with bins, you can see deploy, rollback. Oh yeah, everyone should have a help, of course. And see here. So like here's a unicorn extension in the bin directory. This is just a bunch of bash scripts with the executable bit set. And by default, all of these show up on the command line for BDSM. So basically you can say you have a, you could BDSM unicorn start and it'll start up your unicorn processes. You could BDSM increase and decrease. It increases the number of unicorns immediately or decreases them using the signals for unicorn. And you've got the configuration scripts and stuff like that. So, I don't know. It's a neat idea. I've been having a lot of fun with it and I'd love for some fodder. Anyways, I'm done. That's enough. This is a quick talk about a project I started. It's called Giddy. This is Gilly from Saturday Night Live. I blame Ben maybe for thinking of this character every time I talk about Giddy. What is Giddy? It's a Git hook manager and it does it unobtrusively. So it lets you install hooks from a common repository and it lets you share hooks with other developers. So if you're on a team and you want to keep your hooks consistent between your team, this is something you could use. Why would you want to do this? Oh wait, well, it's also unobtrusive. So it doesn't actually change Git. You're still using Git. It's still the Git you love. And your repositories don't become dependent on Giddy so it's very transparent. Not like stacked Git. It's not a different distribution of Git. Okay. This is not how you install GNU Screen. And here's a live demo. So here is why you might want to do this. Does anybody use sub modules? Yeah, anybody hates sub modules? Yeah, okay. So one of the hooks lets you, or takes away some of the pain of using sub modules. So here I've got a project. It's a super project. It's got the sub module directory. This is a sub module. And if I switch to the next branch, it doesn't update my sub module. It makes me run Git sub module update. So if I run Git hook in it, this installs Giddy into the repository or sets up the hooks. And then I've got these hooks that I can install and Git hook install auto sub modules. And when I check out master, and then back to next, it automatically updated my sub module. It did it intelligently too. There's some logic here. If I go to a story branch, it also will auto fast forward your branches as well, your sub module. So if I go into here, I'm, you know, it updated my sub module. So there's that. And then sharing. So the way that it works with sharing is, you know, we've got Tim and Jim here. Tim publishes a hook to origin and then Jim receives it. The way that it happens in a completely detached branch. So no matter what branch you're on or if you check out an older version of the code, you're always using the latest versions of the hooks in the repository. And they get updated with git fetch. And I'll just do a live demo of that. So up here we'll do Tim. Okay. I'm getting lost with all my windows here. Can you see it? Big enough? Okay. So the first thing is you do have to initialize it for sharing because, well, read the website. Why? It's not on by default. Oh, geez. Failure. Okay. And then here, I gotta run it again. Okay. So if Jim is doing evil white space commits, some people really hate that. Git by default lets you do it. But if I publish a hook for clean patches, git hook install clean patches and then share it and then publish it, no more evil white space. Over here, after I do a git fetch on Jim, that hook automatically gets downloaded and the next time I run a git command, it will get activated. So when I try to add more evil white space, and let's say a dash m, and it said trailing white space. So it didn't let me commit it. There's a couple other hooks for not doing. So if you want to not commit debug code, you can put no commit in there and that's it. Don't panic, it's well tested. Get it from my GitHub account or you can just do gem install giddy to play with it. Thanks. So I made all these slides in the last two hours so we'll see how it goes. So there's sort of this reoccurring theme in a lot of these talks about Agile. Who knows what Agile is? Yeah, exactly. So this is what Agile is to me. So I didn't put this in my slides but when Pat Max was talking about his ruby love and how it kind of started negative and then grew and grew and grew, that's sort of how my Agile experience went. So when I first started doing Agile or was exposed to it, I thought it was really dumb and it was particularly dumb because it wasn't really working. And I'd say things like what we're doing is stupid and like let's do this smart thing and the person be like well that's not Agile and then I was like well Agile people don't do smart things and then we kind of get in arguments. But the way I think about it now is you have kind of two buckets. You have some Agile practices that are about planning and they're about engineering. So like all the XP stuff and like TDD and that kind of stuff is what I consider the engineering and then planning's like stories and this kind of like hand wavy business value stuff. But at the root of it, it's fundamentally like a developers movement or it kind of started. If you look at the manifestos all written and signed by developers. And then there's sort of like a token tester there, Brian Merrick, I don't know if you've heard of him. And then at some point, like even though they're coming from a different direction, like you had to recognize product owners and that kind of gets talked about in Agile. But there's like the circle of happiness and then there's like all these other people that like have to be doing stuff for things to really work. But like Agile doesn't even really know they exist or doesn't know how to talk about them. So then I kind of feel like I've been talking a lot about this problem between developers and operations teams, but I think this really exists between pretty much any role in most organizations. You have people that have different ideas about the world, different worldviews and that could be sales and marketing, that could be developers, testers, that could be developers and product managers, whatever. But you kind of have this wall of confusion between all these roles and that makes people unhappy. And then like they usually don't really talk to each other. Like they have like these weird protocols to talk to each other and then like things get really messed up. So the way that works out is you have this like between every role and then it's like this is like most organizations. So you kind of have like this setup and you're trying to navigate this thing and then right here that's the customer. He's kind of like outside that whole thing. So he's trying to do this. So let's get met. So like what are we actually trying to do? In most cases like people think, okay like I'm a Rubyist or I'm a programmer or whatever and I can hack on stuff and make it do what I want. And like computers will do what I want. But at the end of the day, like the fact that you could program means that you can manifest your thoughts and you can make stuff happen. And if you do that, then there's a potential to recognize little inefficiencies in the world and everywhere there's an inefficiency, like you can solve that problem and you can make cash. There's like ways to turn that into cash. And people do that all the time. That's like we had a comment earlier about how business people are like bad and they'll kill you and evil. But like really all they're trying to do is like, like they're playing this game and like who likes video games? So like video games are like you have this score. So like play a game where like the score you're trying to win is like to make a bunch of cash. Like that's basically what they're doing, right? So it's like reframing it so that it's fun to like try to make cash. It gives you this opportunity to enable a business. And the reason that you can do Ruby in most cases is because you have money and let you eat and like pay rent and stuff like that. So you can enable someone else's business where you can also enable your own business. And I would encourage, I mean this is going back some of the experiences I had in the last year, but like there's a lot of problems in the world. There's a lot of inefficiencies and you can go out and solve them and think about them. And in order to really do that effectively, you like you basically have to solve that wall of confusion with all those roles internally inside yourself and then eventually like build a company that has all those roles. And if they're all able to communicate effectively, like you're gonna be able to do things a lot better. So I don't know if anyone knows who Jeff Patton is. He used to work for ThoughtWorks. But I feel like this is a problem in a lot of software, where you have people who are not, it's irresponsible to like take a contract where you're like, oh yeah, I'll just build that. And it's like, why, right? Like what is the guy asking for? Well, I need, this is a quote from John, but I need a shovel, well why? So I could dig a hole. So why, so I can plant something and then why? Cause I wanna grow some food and well, here's a sandwich. It's like problem solved, right? So there's other ways. And then this is a quote from Alistair who talked earlier that it's basically like, there's only us, so like let's get together and like do these things and where you can do that internally or with the organization. There's lots of all these other things going on. They're cool. They like add value to Agile. This was a talk last year, if you remember. And then this is also like, you know, Mountain West Ruby Conference, so represent. And then it's like, it's continuing. So you just gotta keep doing this, right? So this is like the short little pitch. There's a conference called Agile Roots that I founded with Kay and a guy named Nate who's not here. We had a conference last year. It was awesome. If you go to Confreaks, which is recording this, there's Agile Roots videos from last year. I highly recommend you watch the Artisanal Retrofuturism Cross with Team Scale Anarcho-Syndicalism video. And you're all invited. Hi, my name's Howard. This is my first conference ever. And this is my first talk. Thanks, thanks. Right, and I have issues. My program is slow, my program is legacy, and my program is crap. So it's, and my program is incorrect. So like, it's a total fail, right? And how do we manage all these? Making reliable distributed systems in the presence of software errors. This is the PhD thesis of Joe Armstrong. He's the inventor of, co-inventor of Erlang. And in this paper he talks about, you know, given errors, how like, just unavoidable to have errors within your system. But you still need to somehow derive reliable software from just like this bowl of mud. And how do you do it? Turns out that concurrency, reliability, and scalability, they're exactly the same thing. If you get one, you get all the other. And Erlang is a story about how you get concurrency and all that from this kind of three-legged stool. If you miss one, then you don't get any other. So it's a story, and if you read this, then you'll tell you a story and either you buy it or not. And it could be Erlang. But do I really want to program Erlang? Not really. So, but we can still from Erlang. Just like, get the ideas from Erlang and we'll use Event Machine and NQP and Donkey. ASS stands for Asynchronous Server Service. Right, and here's some demo. So I'll show, I'll show how you can have named actors with zero configuration, with low balancing, low distribution, store them forward with zero downtime, and upgrade, no JS style, event based programming. Okay, so we'll start. So you require RubyGems, and you require Donkey, and you run everything in Event Machine. You create a Donkey server, Donkey Actor, actually. It's a reactor with a name, and then you define callback. So the callback would, the callback will respond to any message sent to this actor from anywhere, and it's mediated by MQP. So you just echo the message back, message.data. Then you reply to the caller. Right, that's it. So you get low balancing or that, just doing this. So we can give this a go. So the server is running, or maybe not, here. Wrong method. Right, so you have a server running, and you can start a client, which is, what should I do, have? Right, so here's a client that sends in a message once every second into the server. You can see the server not doing anything, just respond back. But we can, we can tell the server to print something immediately. So you can get a message, it's coming in here. Right, so and very suppose the client is still running, and if you kill the server, the client are still sending requests into the server, but you don't want to lose this message. So this message are still storing the queue. And if you start up the server, then it catches up. So it's like magic to your downtime, all great. You can have, you can run multiple instances of the same server, and it will be low balanced to a server. So I can run another instance here, quickly. Right. So now you have two instances of the server getting requests, and it's all low balanced through AMQP. And so you can upgrade one instance. So this will be server two. So I just like, maybe I did some fixes on the server, and you want to upgrade it. And now I did an upgrade, I can just run the actor again. Then you'll be the new server running the new code. But all while I'm doing this, like there's no downtime. And the other server instance is still serving the request. So we can do this kind of high availability programming trivially with event machine. And it's based on event machine, so it's also high performance and with callbacks. So it's pretty cool. Check it out.