 How much time? Thirty seconds. Thirty seconds. It's actually thirty weeks. We all teach in the UW certificate program in Ruby, and I just wanted to introduce everyone that teaches, and also we have some previous students here in the audience. Could you all stand up and wave so you can talk to anyone of us teachers or the previous students that have gone through the program? And that's it. Google UW Ruby Certificate. And you'll find out how to sign up for the class. Thank you. Howdy. Okay, my name's Kobe Rankwist. I wanted to cover three topics. One, there is... How many people in here have built financial or software-run financial institutions? Okay. If you want to do that again, you can look up share1.com on the Internet. They are a company that builds software-run credit unions. They eat their own dog food or drink their own champagne to the point that they've now opened their own credit union and have been running it for several years. They are looking for Ruby and Rails engineers, share1.com. A good friend of mine runs the company. They've been in business for 25 years. They are not a startup, but they are a progressive company. Topic number two, chronological order. February. First weekend in February. It rains. It snows. You're in Seattle. Come down to Los Angeles. We are having a Los Angeles Ruby conference. That'll be the first week in February. We're going back to our roots, which means we're going to hold the L.A. conference in Orange County. And we're doing it at the Marconi Automotive Museum. So you get a weekend of Ruby and a weekend surrounded by very expensive cars. Very cool, expensive cars. Third topic, following up Los Angeles Ruby conference the first weekend in February. We've got Ruby on Ales in Bend, Oregon. That will be the first weekend in March. The only conference with an open bar. And I've got 10 seconds left. I'm going to turn them over to whoever's next. Thank you. Hi, I'm Jeff. So I'm just trying to drive a point home right now. It's a little bit of a rant. Mobile first. Make your frickin' website mobile first. When you build it, look at it on a phone. Just look at it. If you don't do that, you didn't do a good job. I'm just going to drive that home. If it just, I said two minutes. That's about 30 seconds. You didn't do a good job if you did not do that. Because if somebody comes to your site and they open it up and they're like, I can't see certain things. I have to zoom in and zoom out to see certain things. I have to wear reading glasses if things get small. Don't do that. That makes me mad. I leave your site. We good? All right. So a haiku machine. A haiku machine. It builds haiku for pleasure, but rarely makes sense. So I've got a little bit of code that you are welcome to. It's JavaScript. Again, I apologize. So this actually came from Dr. Richard Bartle, and I adapted it to modernize it. But this is the guy who invented the mud back in the 70s or whatever, and there's a little bit of code that will just run and create randomly, you know, just random my haiku. So if you want to play with this, there's a web service. It's harokumachine.harokuapp.com. And you can get a nice little, what? Haiku machine. Sorry. Haiku machine. Haiku machine.harokuapp.com. And you can just get a little JSON with some haiku in it. Make something fun. There is a, there's a Hubot. We've got a Hubot adapter for this, so you can be in your chat room. You can ask for haiku, and it'll maybe bring some tranquility to your life. And there's some source code that you can play around with under my, on my GitHub page, dnh slash haiku machine. Haiku machine. I think that's it. Thanks. All right. Well, I guess, apparently my brand new MacBook Air has broken display port. Anyway, I can make my point without showing you anything. Basically, Twitter Bootstrap has classes like Span 12, things like that. And those are really handy for doing grid layout. Great. It makes really easy to build websites that fit a grid and do things like that. That's awesome. But Span 12 in your markup is not very semantic, so if you're using something like SAS or less, you can use the extend keyword in SAS to basically have semantic classes that are a Span 12. And that's a great way to keep your CSS kind of consistent and keep your markup semantic and avoid having Span 12 because that's a lot like tables. No, it doesn't work for some reason. Yeah, so don't put Span 12 in your markup because that's lame. Thanks. I'm going. All right. So I want to show you some code, some Ruby code because tomorrow I'm going to talk about surfing and there's not going to be much code. This is the Engine Yard add-ons thing. We have add-ons for Engine Yard Cloud and I wrote some code for it, most of the code for it. And I wanted to show you the example application that I wrote for it. And the cool thing about this example application is that this documentation contains a lot of code snippets about how to talk to our API and each one of these code snippets is generated by the code. And it's kind of hacky, but I think it's cool, so I'm going to show you. So here, I'll run it first. I also have this script called script documentation, which runs. It says I need to run my test first and then when it finishes, it pops up in a browser and shows that. So what you start with here is readme.txtile.erb. Is that big enough? And you'll notice that it's like a normal textile file except that there's ERB comments here for things, right? And if I take that and I look in the code for it, you can see that it's like this crazy syntax I came up with for putting comments that mark off pieces of code as interesting. And let's see if there's another better one. Here, here's a result. The result is interesting, because this is saved off from a variable, so I saved my chronota URL. My registration call ends up in a variable, so I'm saving off the Ruby object that was generated during the test, instead of it being a code snippet. It's like a result. And then there's even cooler stuff. Let's see, maybe one of these other specs. Yeah, record next request. So this is the coolest one. This is using RAT Client, which Andy talked about earlier. So this is saying the next request that this thing makes, because it's an API, right? I'm showing you how to make an add-on, which talks to the API for engine art add-ons. What it makes should be recorded in these three parameters, right? And so the response that it makes... Oops. Can I read me? The response is going to go right here, right? And that is done with this request middleware. All I do is like save the requests and save the keys off. And that's cool. Here's my script documentation method. To know that you can do this, save the output of RSpec and do stuff with it. You don't have to just run RSpec using the RSpec command. So I got this parser thing that parses all my code. I run all my tests, and then I do more stuff, and then I write out my file. Yeah, I still got a minute. Cool. Let's talk about something else. So I started extending this out to be more generic, right? Because that was like super specific to ChronoTalk. So I started making this DSL for API tests that I'm going to document things by writing code, and this is both the test and the documentation. And so you run this, and here's the pieces of the code that are performing the thing that it's doing, like enabling a service list of services. There's the setup. This is a test of enabling a service. And then here's like an assertion step. And because I have a RAC client just stuck in the middle of stuff, it's going to record at the point that it runs this thing, and that request is going to go out, and here's my enable service folder, and here's the request JSON and the response JSON that happened when I ran that test. And here's this YAML file that has all the other stuff that I described in that block of code. And now I can make some other thing that takes this YAML and this JSON and puts it to it. Great. So I want to talk about how we're using identity maps at my company. This is Perk. It's a startup just across the lake in Kirkland. So what's an identity map? It's one of the patterns covered in Martin Fowler's classic book, which you should all read if you haven't yet. It's basically a hash that contains all the model objects that you're currently working on, each one keyed by some unique ID. So it functions like an in-memory cache. So whenever you want a particular model, you just look it up in the identity map. If it's there, then you just grab it. If it's not yet, then you load it from the database and then you put it in the identity map so that you have it for the next time you need it. So in addition to a cache, it helps you avoid creating multiple copies of the same object in your system. And that means you no longer have to worry about those copies getting out of sync with one another and bugs happening because of that. You also don't have to worry about having to memorize your objects every time you want to get one object from another one. In short, it just saves you tons of headache, especially as your application gets larger and more complex. So let's take a look at how we're integrating these identity maps into our system. First of all, like Jesse discussed this morning, our models in our system are all plain old Ruby objects. They're not active record classes. We are running Rails, but we've kind of extracted or abstracted the persistence from our models. This is often a good idea if you can do it. There are lots of reasons for that. Active record does have an identity map built in as of Rails 3.1, I believe, but it is disabled currently by default because it still has some issues. Since we don't use active record as our domain model, we don't need it anyway. What we are doing is this. We have a central registry object that we use as a factory for all of our models. So whenever we want to model, we just look it up from that registry object. Now, the registry handles all of the identity map logic internally, so it knows already whether to construct a new model or whether to return an existing model. So all we have to do is just look it up. Now, most applications have multiple kinds of models. You might have users, blogs, comments, and so forth and so on. To handle that, we use arrays as the unique identifiers for our identity map. So this lets us include the type information in the unique identifier. It also lets us support any arbitrary schema to use to identify objects. You don't have to just have a single ID, but you might have some more complex way to identify an object. So those arrays are the identifiers that we pass to the lookup methods. So the usage is very straightforward. So when we lookup models in the registry, the registry needs to know how to construct the objects if it doesn't already have them. So on app initialization, we configure it and we teach it about each type of model in our application. So we tell it how to recognize each type of array identifier by providing a pattern. And then we match the pattern. And then for each of those patterns, we tell it how to construct that kind of object from the elements in the array. In these cases, the ID happens to be the second element in the array, so it's really simple. We have some more complex examples in most cases. You want to scope your registry to a particular request if you're running a Rails application, for example. This is to control your memory usage, and also you probably want to isolate the data in your request from each other. And we have a rack middleware that clears out the identity map after each request to do that for us. We have a bunch of additional features that support the various use cases that we've encountered. This has been in production in our systems so it's quite stable and it's worked out really well for us. It's enabled us to really simplify a lot of our application logic. And the good news is we just open-sourced the system. So if you're interested, check it out. Gem is called ID Registry. It's also on GitHub, and come talk to me if you're interested in discussing any more of this. Thank you. So let's say you're in the business of making something, like most of us are. There are lots of different ways to make things. There are lots of different processes for making things, but most of them boil down to something like this. You have a lot of different steps, and you have a lot of things that do the steps. You might own a lot of really expensive machines. You might have a bunch of really highly-paid people. But what is the best way to get the most out of your investment in all these expensive people and all these expensive things? Well, you might think the obvious answer is, well, let's make sure that we use each of them to 100% of their capacity all the time. And so that sounds really good, but what is the consequence of that? If you try to use every single machine to its maximum extent, well, any time one of the machines has a little blip, then another machine is sitting idle. That's a disaster. So we have to have some work for it to do while it's waiting for the initial blip to get over. So what you start doing is you start batching up work between the steps. So now you have step one, and then there's a little batch, and then there's step two, and then there's another little batch in step three. But the good news is that you're using all of your machines to 100% utilization. And of course the machines won't be totally exactly matched up. Maybe one of them can do five widgets an hour, and the other one does six widgets an hour, and you can only buy them in certain increments. But that's okay, because the batch kind of smooths all that out. So this is all great, right? The only problem is what if somebody comes in and says, well, hey, nobody wants the widgets that we're selling. We need to create a different kind of widget. Now you're screwed. So what I'm trying to get across here is that that kind of model doesn't work. At least not if you're in the kind of domain where what people want changes all the time, which is basically the domain we are in software. But if you look at the way we build things, you'll see a lot of similarity. We have this idea. We want to take it to production. We have a lot of steps, perhaps a lot of different people and systems that it has to go through. And the way we deal with that is, well, let's branch. We'll have the release that's out in production and then we'll have the release that's in QA number two and the release that's in QA number one. And basically you end up in the same situation. Because what's going to happen to you is that someone is going to come to you with a bug about something that someone is going to come to you and say, hey, there's a bug in the system. And you're like, well, which system is it? Is it the system that's in production or is it the system that's in QA number one or QA number two or on my desktop? And it becomes the mental train wreck, the same thing that Katrina was talking about. This is not what makes you happy. You need to simplify, make it so you don't only deal with a little bit of work at a time. So there is an alternative. How many of you have heard of the end-on cord? Not only one. So in Toyota's lean production factory, they have assembly lines and they have a thing called the end-on cord. And whenever anybody sees something wrong in a car that's passing through the production line, they pull the end-on cord like this guy is doing right here. And what does that do? It stops the entire production line. No cars are rolling off the end. No parts are coming in the middle. Everything stops. And this sounds completely insane. But what it does is it means that everyone can go figure out what happened. How did this defect get introduced? And how do we make sure it doesn't happen again? Go back to the beginning. Restart the production line ever so slightly, 1% more efficiently. And what they optimize for at Toyota is cycle time. How long does it take to go from parts to car, or in our case how long does it take to go from ideas to production? Again, the reason that you want small batch size is so that you can change fewer things at a time. You have fewer things you have to keep in your head. So this is all great. The problem is how do you do this? Well, you've probably heard of continuous integration and continuous deployment is the logical extension of this where as soon as you check in a line of code, it could potentially go through automated test, automated build and automated deployment all the way to production. Which sounds pretty good. Okay? Thank you. Hi, my name is Lee. I work for One Hub. I just wanted to tell you guys a little bit about our staging deployment. Something we did in the last couple of weeks that I thought was pretty cool and some of you might find useful. So at our company, we've got a staging server and whenever someone fixes a bug writes a new feature, it gets moved to the staging server which is a lot more like our production infrastructure before it gets put on to production. They press all the buttons, give it the thumbs up, and it gets deployed. And one of my responsibilities is making sure that all goes smoothly but that's kind of a lame responsibility so I've written as much code as possible to make sure I don't have to do anything. So oftentimes many topic branches get staged per day. It's just a big overhead. I don't want to have to deal with it. So we set up a system whereby when a developer wants to stage a branch, they go check out this branch called Stage that's just always got what's on staging right now. They merge bug 1503, fix bugs into it, and then they push. And we have a Jenkins server sitting in our office and GitHub tells Jenkins that there's a new push to stage and Jenkins goes about his business. Jenkins is a, for those not familiar, it's a continuous integration server so it basically sits there and when you tell it to, it'll run all your tests. It'll tell you if your test passed and you can do whatever actions you'd like to after that. So we have two Jenkins jobs. We set up the primary one. You see on the top it's called DOPEO. That's our main application. That just runs the whole entire test suite. Takes about 10 minutes. And this second, this bottom half here shows you part of the configuration of that job. It lets you configure post-build actions so you can actually build another job when the first job finishes. Awesome. DOPEO deploy job gets hit and that just deploys the code to our staging server. If it doesn't pass, then it never gets deployed. Everyone gets alerted. We get an email. The person that broke the build gets to fix it, redeploy it, and then everything goes green and it's awesome. So like I said, it gets deployed automatically just to staging. We still manually deploy to production. We don't have continuous integration setup because that's kind of scary. I'm going to say grow and I think someone else is going to talk about that a little bit later. That's all I got. Keynote. How does it work? Hey, I'm Chris at Xeomatics. You can increase my cloud score if you tweet about me. Very good. I was a philosophy major in college before I dropped out, but this is the short version of this. This is about happiness. The short version, Reed Aristotle, very cool guy. Looks like he's holding a Dell in that one, but that's either here or there. Something that we care a lot about is money. Making money. That sounds really cool, right? There's been a lot of science done on this. People who do science things. Like most things in science, it turns out that there's kind of a bell curve of where money will affect your happiness. It turns out that once you go beyond about 75k a year, the increase in happiness by increased compensation. It's kind of like a law of diminishing returns. So it doesn't actually make you that much happier for the effort, for the stress that you put into actually getting that extra money. So pop quiz. Here are two jobs. Magazines. I don't know. That was the example given. So you can either get paid 65,000 when the other people at your level get 68,000, or you can get 63,000 and the other people at your level get less than you at 60,000. So many people here would choose magazine A, where you make more but less relative to other people. Okay. I'm not good at numbers. That's about 50%. So... It's all science, you know. It just makes sense. So it turns out 84% of people when they are asked this would choose the the job where they would make more, but they would make less compared to the other people. People really like money. It's a cool thing. When asked which job would make them happier, about two thirds of them acknowledged that their choice was not right. They knew that they were going to be less happy, but all they cared about was making more than the person... or making more in the absolute sense. So why does this matter? If you want to be happy, one of the best ways you can do this, be like Gabe. At Valve, I think a lot of you know this, there is Gabe and he is just one of the company and everyone else. They have a completely flat structure where there is no arbitrary bureaucracy or kind of like people above each other. There is no senior developers and associate developers and whatever. I don't even know. I'm new to this. I don't even code yet. I don't know what the fuck I'm talking about. So that relative status, we get really catty. We get really into that stuff. They are just words. They are made up. So first world problems, another way to tell about how happy you are. We get neurotic about these things. These lack of freedom. Freedom is really crucial. I didn't even make these up. Why are you laughing? So freedom to us is actually very important. We would rather be more free and in an objectively worse position than otherwise. Traffic is a great example of this. If you can, you should pay more money for rent and live closer to your job than living out in the suburbs somewhere. With all the preppy people who wear bonobos. Because I went to lunch with them. I told them all about bonobos. They get it. Because traffic makes you really upset. The reason is you're just out of control. There is absolutely nothing you can do about it and in your brain you just freak out. Because we were designed on the Savannah where you always got to be able to run away. It's true. Science, crazy shit. So this is a great picture. I really like mustard. If you go to the supermarket you're like, I'm looking for some mustard. They're like, I got mustard. But they have every kind of mustard out there. Like how do you pick? I don't know. This is another thing, when you're programming and you need to pick a technology if you have four or more choices just throw up your hands and be like, it turns out after about four or five choices if you have more than that number of options your brain does the same kind of thing where it can't decide between them. So you just start picking made up stuff. You're like, horseradish? I don't know what that is. We'll go with that. Because your brain needs something I guess maybe like prologue. I made that up. It needs something to distinguish against and so it just picks values. It just starts throwing them out there. And here, Abercrombie at Fitch don't go there and shop. You probably wouldn't anyway. But the reason they play really loud music same reason you have all this mustard is that if you play really loud music your brain can't make objective decisions and so it gives up and you just impulse purchase. That had nothing to do with happiness. I don't know. Alright, there we go. So I'm going to talk to you about how you can do or do not but there is no try. Alright. There actually is a try but you should try to avoid it. Huh? Huh? So here's the setup. I have a current user method in Instant Generic Rails application. Currently I don't have anybody signed in so my current user is nil. If I call current user.name of course I'm going to get undefined method name for nil class. So far all pretty standard stuff. If I call current user.name then I get nil instead. And so try is a method that's baked into Rails but it doesn't cover everything. So try does not instantly you're calling a bad method on an existing thing. It also does not cover calling a chain of methods against the same thing. So if you get nil back as a result of try you call something on that so when should we use the try method? So this is my opinion on try. There's like a pixel in the middle. You can't see it from there but it's there. So what is going on here? There are actually a lot of variations of try that existed before the flavor that got baked into Rails. Rails uses a very light implementation of the try method and I didn't realize this until I went exploring but it's not actually in pure Ruby at all it's a purely Rails invention. So if you want to take try and expand it out even further you can go with the uber try method I wrote this. You just go in your monkey patch nil class and you overwrite method missing with nil and bam all of the try all of the time. You'll love it. Now if you take a second look at this what we're actually doing here is nothing more elaborate than just error suppression right? We're taking an error generating method and we're overwriting it. So I was talking to my mentor Jeff during Hungry Academy Instant Plug and Jeff had a wacky idea and that was to take current user and either provide the user or a kind of a fake ish user that knows how to respond to a name and now I'm thinking okay this is good but it's not. So if you like try you'll love user.create if that's cool with you you'll love article.mightpaginate you'll love rakedbmigrate I guess and you'll love posts.each consider doing oop dog is not impressed with this so it all of this is just error suppression and it's doing this weird logical branching magically under the covers it's all of the stuff that we don't like as Ruby and Rails programmers we are code smiths we're not just programmers we are code smiths we know when we have objects we know what those objects can and cannot do and we tell them when to do it we don't make suggestions at the end of the day thank you. Okay how many people are here you just scrub that's a lot of people so I'm here today to talk a little bit about lean oops sorry that slide I'm here to talk about lean so lean is agile when I say agile it's a little agile all the things that you read about in the agile manifesto like lean is responsive making sure you have working software that focuses on people those are the things you see in the agile manifesto and those are all things that are lean so there's consistency between lean development and little a agile development but lean is con bond does everybody know what con bond is alright that's good who uses con bond in their normal day-to-day development so it's a little bit smaller there but the key things about con bond is you visualize your work you limit your work and process and you optimize what you're doing for flow that means you're things are always moving in a flow like batch sizes and it kind of sprints those things kind of go away because you're prioritizing what you're going to work on and you're going to pull that stuff through some type of process so lean is not capital A agile and to me that means it's not scrum it means you're doing things you're never wasting your time estimating things because you're always ranking what's most important and that's the thing that you work on it's very continuous again it's not sprints the key difference between lean and scrum based types of working it's the key fundamental difference everything that is not lean is basically push and if you're pushing you're probably coming up with some kind of what am I going to get done in this next two weeks sprint or what do I mean to get done in this next sprint well what value does it really add to the whole process because the idea is you want to get stuff done and get it to your customers so lean is not estimating and there's a saying that metrics are the bedrock for mental slavery so lean is not time estimating you're pulling a number out of your ass anyway so what does it really give you between now and the time you're trying to get a sprint done and all the important metrics for lean just kind of fall off there's this idea of cycle time how long does it take to get a card if you're working on something through getting on a board and moving it through done lead time how long does it take before you put a card on the board before you actually start on it and work in a continual way tools for lean development like Pivotal Tracker or Trello the typical Kanban board is just a board with a wall with lanes on it that you pull cards through and why it works it makes it very easy to find bottlenecks you could build in slack into a system if you're trying to speed up your cycle time if you have bottlenecks you know where to actually put people or resources to work on that slack so it helps you work smarter and it helps allow project managers to do things that are more important than figuring out where you're at on your sprint and that's it so give it a try I would say give it a try there's something called Lean Coffee in Seattle it's a cafe cacao on Wednesday mornings at 8.30 if you want to learn more about lean or applying it to your work it's a great meeting to attend I'm Elise sorry Shane I looked at my slide I'm one of the Hungry Academy people those two talks the one about developer happiness and the one about try I thought they were really hilarious and those were both Hungry Academy folks so if that's a testament to like how awesome the program is I can't think of a better one so my background is in marketing I'll talk a little bit more about that tomorrow but I think marketing is important for everyone particularly developers and I just want to tell you one tool that I think is very important so who of you thinks that marketing is like this a lot of marketing is pitched this way and I think it is stupid this is not what marketing is about views on marketing are very wrong so wrong what marketing is about at its core is knowing about how to get into particularly when you embark on a new project or revisions to an existing product the thing that I like the most is called a situational analysis and this is the first thing I thought of sorry so do this this is like a marketing 101 first day thing and it totally applies to software development so there are three parts to situational analysis that may sound sort of familiar but this is again like old school marketing stuff first is think about your customers that male shopper that guy doesn't exist so think about who your customers are what their preferences are what their demographics are if you're making a really awesome product and the only person that wants to use it is you it's not a good product competition so if you've got other people in the space that are doing things just as well and adequately serve your customers needs then that's going to impact how well your product does and also capabilities what are you good at maybe you are an awesome designer and can really just like rip it over some crappy enterprise software system that everybody else is going to love think about what you're good at as it applies to the new product that you're deciding to build so why the fuck not let's try this now I was trying to think of a good idea for doing this in front of the hungry academy class and this is the one that I came up with I hope you like it oh gosh I didn't plug it in here we go founder of dollarshaveclub.com what is dollarshaveclub.com well for a dollar a month we send high quality razors right to your door razors right to your door yeah a dollar are the blades any good no our blades are fucking great each razor has stainless steel blades and aloe vera lubricating strip and a pivot head it's so gentle a toddler could use it spending $20 a month on brand name razors 19 go to Roger Federer I'm good at tennis and do you think your razor needs a vibrating handle a flashlight a back scratcher and 10 blades your handsome ass grandfather had one blade and polio looking good pop up stop paying for shave tech you don't need and stop forgetting to buy your blades every month Alejandro and I are going to ship them right to you we're not just selling razors we're also making since Eric said I could only have five minutes I'm not going to finish oh thanks you guys just such a good video Alejandro what were you doing last month what are you doing now I'm no Vanderbilt but this train makes hay stop forgetting to buy your blades every month and start deciding where you're going to stack all those dollar bills I'm saving you we are dollarshaveclub.com and the party is on I think the dollarshaveclub is a contrived example but in fact it is not they are this is like textbook case study on knowing your customers knowing what you're good at and knowing what your competitors are so I already kind of went through this exercise with a group of people and this is what we came up with and I think they really hit the nail on the head in terms of getting their product mashed up directly to customers so you know these are tech-savvy people that want simplicity, convenience and the good design and funny commercial actually helps so yeah man you should try this okay thanks I'm Gary Bernhardt I'm specialist I get a lapel microphone and I own a company called destroy all software you might have heard of it and the title of this talk is programming is easy now you're a Rails programmer writing a Rails app you have a thousand lines of code which is represented as a large rectangle on the screen right now and I'm not talking about boot.rb I'm talking about actual code you typed into your text editor into a model or a controller which are the only two places code can ever go and the problem with this is that you're a dog at a computer and you don't know what you're doing because you are surrounded you're surrounded by Rails so if we add Rails to that rectangle your application which is one thousand lines a whole thousand lines of code is the blue part now zoom in so you can see where the blue part is it's one pixel tall on this graph it's very insignificant now you feel afraid and you feel alone in this world because you don't understand how Rails works but if you just look inside of it you can make sense of it for example here is the actor record create method which you all use many times and it works exactly as you would expect the reason you can look inside of Rails and it makes sense is that Rails was written by dogs at computers who don't know what they're doing now it doesn't stop at Rails in fact because if we add MRI to the graph suddenly Rails is a very small sliver at the bottom two hundred thirty thousand I think lines MRI is about a million and your app is actually invisible now it's zero pixels tall it is completely insignificant in this world and you can look inside of MRI and it makes sense here is the implementation of array collect and if we look at the part that matters it allocates a new array it loops over each element it invokes the block on each and then it returns all those things it's exactly as you would expect because MRI was written by dogs at computers who don't know what they're doing all the way down it's dogs at computers speaking of people who don't know what they're doing let's talk about the service stack you can see here is mySQL mySQL cluster in Apache and you can see that suddenly the even Rails itself is a very small sliver Ruby is getting much smaller let's add some more things the user land this is everything from GCC to GNOME and by the way you can even read GCC it makes sense out of some parts of it now I want to draw your attention to this part of the code which there are no statements on the screen right now this is a single conditional and I picked this one because it fits on the screen actually there are much bigger ones now it's clear in this case that dogs at computers wrote this code I don't think I even have to tell you that but let's keep going Firefox is 6 million lines of C++ you can make sense out of all of those lines because they were all written by dogs at computers and finally the Linux kernel is 14 million lines of C code it might be scary to you but think about how many people it takes to write that much code it's not like one dude it's not like Linus went away and wrote 14 million lines of code lots of dogs at lots of computers now if we look at some of this code this is code from the actual Linux kernel this is part of the fair scheduler it's this this function besides whether we're about to refresh the metrics that the scheduler keeps so it keeps track of various things about processes to decide who goes and when we first decide are we currently are we currently running are we currently doing a quota refresh if we are then obviously we're about to do one by this definition and also if we have very small amount of time left before we're going to do a quota refresh then we'll say yes we're about to do one and otherwise at the very end we say no these things all make sense if you step through them because they were written by many dogs at many computers and you are also a dog at a computer so you can understand what the other dogs did now I think I hope that there are two results that this has first of all you should feel sort of insignificant um your Rails app is invisible almost invisible compared to Rails and Rails is almost invisible compared to the rest of the stack but also this should be sort of empowering because it's dogs all the way down like dogs at computers can understand what other dogs at computers wrote because you know the human already understood it in order to create it which is different than biology or chemistry or any of the hard sciences where eventually you hit a point where you just can't do a better measurement you're screwed by the hardware you have or you make a measurement but it doesn't make sense you don't have the theoretical framework which means you have to go off for 20 years and invent one but in software you know someone made all that crap underneath you it was all man made everything above the electrons so there's no excuse for not understanding it because there are no mysteries here and finally if you only live in that Rails world which is doubly invisible you're basically changing the oil on the car without knowing how the car works and there's nothing wrong with changing oil for a living but it is not very ambitious and I don't think it's very fulfilling in the long term for a curious person so I would encourage you to figure out how the things under you work don't be afraid of reading the source to the Linux kernel it will take you two minutes to download it and you can just start reading through the actual kernel and it will even make sense I promise so that is it thank you very much