 my pleasure. So I just wanted to announce a hack fest we're putting on in August, August 1st to the 3rd, we're putting on a hack fest Ruby for good, rubyforgood.com, check it out. This is a, it's a three day long hack fest to get an entry into open source. We're going to be hacking on social good projects. So come on out. In the DC area, it's going to cost about $200 or less, unless we get some sponsorships. So maybe if you work for a company like GitHub where you have this great project, product, but no one's heard of you, maybe you can sponsor us, they'll get your name out. Or Rackspace or, or whoever. Yeah, so it's going to be three days, all your lodging, all your food, everything's going to be covered, and it's going to cost about $200. We're going to work in open source. If you want to sell it to your work, we're going to have workshops on the second day. We've got one of the guys from the RSpec core team giving a talk in RSpec, and I'm almost out of time. So Angular and building APIs. Thanks. You guys need to send messages between your stuff, right? So normally do that with JSON or XML or something. My laptop has gone out to lunch. There it is. It's not in front of me. All right. So, that's going to be confusing as hell. All right. Where is the thing? Okay. JSON. You're used to that? JSON is awesome. There we go. All right. JSON is cool. This is something called message pack. It's like JSON, but it's binary, at least on the stuff that you can binary eyes very easily. It's totally agnostic as to what kind of data you're transmitting, but it's binary, so that's awesome. That's cool. In case you haven't heard of that, check it out. Also, there's Google has a project called protocol buffers. It's even more binary in that you actually set up an IDL, interface definition language, where you can transmit exactly what you intend to transmit, and, yeah, you're a dog, I heard you like transmissions. All right. Anyway, so those are what we're talking about. Why would you use one of those? Well, let's see. This is hard to see. All right. So just ... There's monitors here in front too. Don't forget. Oh, yeah, sweet. Thank you. Okay. So, short guys can't see them. Yeah. On the left, you've got a Rails controller. You've got your index action. It's responding to the different formats. I just quickly tossed in some mime types so you can get the various formats. It's actually really easy to use these other data formats, except the protocol buffers, you actually have to define an interface definition language, and that's always fun. Oh, there's the protocol. All right. So you have to, like, whoa, yeah, that's not the right one. Go away. All right. Just, well, anyway, this is a file. Okay. So you define your message structures, and that's kind of cool sometimes, but then you have to version them. At least protocol buffers let you kind of toss stuff that you don't care about, so you're going to have optional fields in there. Who cares about that? So then how fast are they? Why would you use these things? Well, you can see if that works cool. All right. I've got a benchmark as to how fast these are, which is actually really surprising. So I expected the really binary formats, protocol buffers, and stuff like that to be super fast, like way faster than everything else, but it turns out I'm really way slower. So I was like, well, that's kind of weird. So I tried it in Python, and let's see. So I wrote the same thing in Python, and it turns out that protocol buffers are, well, they're slower, but they're not as slow as message pack, which was even slower in Python. So don't do that if you care about Python. So I was like, well, maybe it's these dynamic languages. So I wrote it and go. So it turns out that it is, oh, not working. Oh, there it goes. So go, protocol buffers are the fastest, which is kind of cool, I guess. There's a very little memory allocation there. And JSON and message pack are kind of the same. So anyway, bottom line is like, you should probably know what you're going to be doing with your data. If you don't know, then just use JSON. It's cool. I mean, it gets the stuff done, or XML if you're from 1990. But you can, if you're using Ruby on both sides, then you're probably going to use message pack because it's actually really fast. Or then, again, you have to consider how much data you're transmitting. So if you're using, this is 10,000 parses of the various state messages I had. So you see protocol buffers used 2.5 megs. JSON was almost 10 megs. And message pack is somewhere in the middle. So if you are not running it over local hosts, like I am, it might actually make sense for you to do something different than more use protocol buffers and eat the parse time. So anyway, there's trade-offs. I figured you guys should know about it and think about it when you're making things talk to things. Thanks. Hello. Good evening, everyone. Good evening. Hi, I am Sachin and I work at Joe's software. We work out of our Pune office. Okay. So this is very interesting, you know, why I'm talking about this here. Very recently, I got into a bump into a problem where I had to, you know, I had a legacy application and I had to quickly, you know, provide support for a native mobile app. And that had to be done, you know, really very quickly. So that is the real reason, you know, I thought really quickly shared, you know, what I did on that. And this, you know, so somebody would, you know, you would be wondering why I'm talking about it because yesterday we had a great session by a general, you know, here about this. However, let me tell you that, you know, whatever we saw yesterday, that was great. That was an awesome presentation. However, that works great, you know, if your consumer is a web application. And that probably doesn't work if it is a native mobile app. So that's the reason. Let's, you know, see what I'm talking about here. So there, you know, when we analyzed, basically in an application, there are two scenarios which need to be handled so that a native mobile application can authenticate to the backend service application. So one is where the user is created and sign up. And the second is where the user is created when he signs up using a third party provider like Facebook or LinkedIn. These are the two scenarios that have to be handled. Otherwise, you know, the application won't work. So as a standard application, you know, API implementation, the solution is obvious. We had to enable, you know, token authentic cable and add an API framework. And once you do that, if you go back, the first scenario, and if you see this, is it visible to everyone at the back? Okay. So basically, a client is a mobile app, and it, so get token and get data are essentially APIs. They are going to make call passing the credentials. These credentials are sitting at the backend server. So the server authenticates the user and sends back the Outs token. And henceforth, you know, the client can use this token to get any data from the backend server. However, this is not going to work in scenario two, because a typical native mobile application does not authenticate with the backend server. It uses the SDK provided by the providers like Facebook, Twitter, and it authenticates directly with the service provider. And then it, once it is authenticated, it would expect the backend service to return data for a particular user. This is sort of complicated. And you know, you can't even store the credentials. You can't pass the credentials to the backend server. Any guesses how to solve this? Anyone here who has done this? Chewing gum? Chewing gum? Oh, yeah. That's what I do. Great. Very good. That's what I did. And, you know, I got the solution. Okay. So basically, what you need to do is you need to pass back the Outs, Outs token that you get from Facebook or Twitter back to your server. Along with the provider, that is, so for example, Facebook and the UID, which is essentially the Facebook UID. If you pass these three details to the backend server, the backend server will be able to serve data based on the user. However, there is one trick here. When you pass this information at the backend server, you must authenticate that the UID that has been passed belongs to the user who is asking for the data. And that's very simple to do. You can use the access token, call the provider, ask for information, and validate it against your UID. If you do that, you're good, the server can send back the information. That's all. Thank you guys. Good evening, friends. My name is Ghani and here my colleague Siddhant with me. We already have spoken on accessibility on the first day after the keynote of DHH. But after interacting with few of you, we realized that we again need to reiterate what, why, and how of accessibility. So over to Siddhan. So, am I audible? Yeah. So the first of all, what of accessibility? I mean, accessibility issues, issues something that is when I'm walking down the street, I come across someone and I'm trying to ask him for directions. I am and I'm saying, where is XYZ? He says, it's right there. So where? I mean, this is kind of accessibility issues that we even face on the web. Like images not having some descriptive text. So why should you really care about accessibility? I mean, there are blind end users and that's too small a percentage should I really care? No, it's not about that. It's like, if you want to care about accessibility, there is an appeal I would like to make, please do care because if you don't, there would be consequences that you might need to face when there are legal obligations, right? So it's not only not only about legal obligations, accessibility actually helps you improve your business. The end user of your web presence increases to great extent. On the first day talk, we also mentioned about 15% of like 15% of world population being disabled and that's like a huge over a billion people. So it increases business. As developers, if you are into accessibility, if businesses are going to need accessibility, then you are on demand. If you know accessibility, you will be getting getting some work. And accessibility helps you to improve search engine optimization. And finally, of course, legal obligations are done, they're done way with, right? So that is why accessibility is important. How should you really go about it? Try and study about web content accessibility guidelines or accessible rich internet applications. Just Google out for WCAG 2.0 or ARIA. And I think you will be pretty much set and there is something more to it, of course. So how accessibility can be implemented? There are three ways. You can learn it yourself. You can get a professional training. And third way is to get the subject matter experts and the end users involved. Here, when I say end users, I mean to say the screen reader users who are actually the end users of who can tell you and who can certify whether the site is really accessible or not. So we also are into accessibility. We do provide trainings. We conduct the workshops and certify the websites whether they are accessible or not. So do get in touch with us to know more about accessibility. Thank you very much. Thank you. Go ahead, Andre. Excellent. So my talk is pairing from the remote world of your couch. And we are commencing let down number five in three, two and one. So who is this Mohawk guy that is currently talking to you? I am a software engineer, engineer at Articulate. Now what is Articulate? Articulate is an e-learning company. We focus on creating tools primarily designed for the teacher and trainer. And we have 120 employees. Roughly I couldn't figure out exactly how many people we have. But we have zero corporate offices. Everyone works remotely. Yeah, that's a very exciting thing. But that causes some interesting things. So for example, I work there. I sometimes work there with my two children. I have to throw them in because they're cute and it has to compensate for my talk. But sometimes I also work here. And now before you ask, no, I am not breaking that. No. No, instead, in addition to being a software engineer for Articulate, I am also the magistrate of fermentation and co-founder of Catamann Brewing Company, a new brewery outside of Chicago. Magistrate of fermentation is there because I thought Brewmaster was just a little too formal. So I want to talk to you about remote development and the concept that remote development is hard. And the reality is it's not. It's different. It's a completely different mindset when you're working. It's focused a lot on time management. The end result is that you have to focus on blocking out your time because the very first thing that I hear every time I talk to someone that does not work remotely is that, oh, well, every time I work from home, I get so little done. I get maybe 20 or 30 minutes of work done. And that's it. And the reality is that's a time management problem, not a symptom of working remotely. I'm going to give you a demonstration. Because I happen to have children and two jobs because I am absolutely insane, I end up doing things like this. This is my usual brew day when I'm working on both children. I started, or both children, both jobs and children. It starts at 6.30. I have my Heating of the Brew Water at 6.40. I watch Magic School Bus with my son at 6.45. Yeah. Coffee number one at 7.05. Milling the grains and preparing the brew at 7.15. I start the mash at 8 o'clock, 8.10. I start reviewing PRs, looking at Pivotal Tracker, and I bullshit on HepChat for a while. Then I actually start the water process at 8.55, begin coding at 9 o'clock, and then start to stop the water process and begin the boil process at 10 o'clock, coffee number two, because I've already been up for about four hours. Standup is at 10.30. At 11 o'clock, I start the boil process. I begin pairing with my pair and on my development team around noon. I finish the boil, transfer to fermentor, stop automating the cleaning process. And by 12.15, I'm all done with that and have lunch. Then I resume pairing. Coffee number three, solo code pair. Well, my pair who works, who's actually on the Pacific Coast, has his lunch. Then we decide whether or not we're going to pair or have a solo code session. Finally, when I'm done doing all of that stuff, I clean my brewery, I eat my dinner, and I go to sleep. On my non-brew days, it looks a lot less crazy. But the reality that we should be taking away from both of these situations that it comes down to blocking out your time effectively when you're working remotely and having the opportunity to make sure that you're having an effective amount of time. And as I put my slides out of order, the key here is that remote pairing also helps with remote development because you are now forced to not only be on your own schedule, but with someone else. And you have that opportunity to be let down when someone shows up and you're off doing something else with your children. So the other concern that I hear from people is the whole concept of live pairing versus remote pairing. So let's look at the technology required for live pairing. You need a shared computer, you need two keyboards, sometimes one, but I feel like you need to have two because I don't want to touch other people's keyboards. You need one or two desks and you need some verbal communication. Now let's take a look at what it needs for remote pairing. Wow, it looks very similar. So let's take a look at the shared computer side and what do we do to solve that problem instead of having a physical computer specifically in front of us. You've got two real options, which is remote sharing of a pair's machine that's just turning on the remote login capability which has SSH and now you're in there or an independent pairing machine. Now your solutions for that, you can have Tmux plus editor plus shell as long as you're using a terminal editor, which if you don't, I'm sorry, but we've got other solutions here for you if you happen to be in that situation. So you've got basically installing Tmux, running a new session with your project name and then your pair attaches session with that project name. Now if you don't do that, you happen to utilize something like Sublime Text, you've got the option of Screen Hero, which is a complete desktop sharing tool and I encourage you to check it out and it's basically connecting on it. If you don't want to have that, you can have something like FluBits, which is an entire collaborative service that integrates with every IDE. Finally, verbal communication, utilizing HipChat video, Google Hangouts, a period, and Talkie I.O. and Skype. No, it's finished. Awesome. Finally, dedicated pairing setups are an option. If you really feel like it, I feel that that's a little overpriced, but you can always utilize a VPS or some middle ground and do not be afraid that remote development means alone development. You can work remotely without having to feel like you're isolated. Pairing is perfectly fine. Finally, articulate tiring, come talk to the Mohawk. Done. Thank you, Heisenberg. That is Justin. Anyway, did anybody get some password resets, emails in the last couple of weeks? Just a few. Okay. I am Justin Love. I help out a little with the Ruby group here. I run the JavaScript group. They were all talking smack about Rails on Tuesday night. I also do independent development and hang out at a place called the methodology center in the suburbs. So we're not going to get rid of passwords right away, but we can add a little bit to it. In this case, it is a QR code. We all know these. We've all seen them. You scan it with your phone. You get a URL. An app on your phone recognizes the URL and logs you into the site. You're done. This is the idea of. Squirrel or I often say SQL, which is a essentially public domain method for doing user authentication without password databases and third parties and all that stuff. And because it is a URL, you can also just click on it if you are on a desktop browser. There's a lot of stuff in the proposal about protecting the master keys. As web developers, you're going to be only concerned about authentication. So your web app generates a cryptographic challenge. It's just a number basically. And then the application signs that with a public private key. There are libraries for this. Hopefully libraries can take care of a lot of it. The important thing here is that for the protocol, the public key is your identity. So it is not shared with any other site. It does not really leak any information. Now the sites are still free to gather your email phone number and credit card number in the store in plain text. The protocol can't help with that, but at least the protocol itself does not require shared information. So this is actually once you get libraries to take care of the hard implementation bits, pretty easy. And then the real world comes along and the protocol starts to get a little bit more complicated. So there is a full protocol here behind that initial request. And there is a two step process. And this is all to help with like men in the middle and those types of attacks where you say you check with the server, make sure it's the server you wanted to contact, and then you say, okay, now log me in. So there's some extra stuff here. I'm playing around with some libraries that will hopefully do this. Other people are as well. There's a whole bunch of activity on a mailing list. There are challenges. I'm not going to talk about password challenges because you know they all stink. So there is the protocol complexity. Hopefully libraries will reduce that. It is still in development. The person who came up with the idea is still working on the first implementation and some of the specifications are still a little bit poorly specified because it hasn't been nailed down yet. But I think it would be interesting to look into. And probably the biggest thing is user responsibility. The ideal here is the user controls their own private key. So there is nobody to send a password reset link to. You might be able to do it out of band and say, hey, reset my account so I can reconnect. But it is going to place a lot of responsibility on the user to create effective backups and things. So it might actually be like a social and user experience issue to really get this adopted. Now why am I telling you about this? It's simple. You are web developers. You have built the current web and you will build the future of the web. People talk about how bad passwords are but nobody does anything about it. But you are the people who have the power to get rid of passwords and give us all a better, safer world. So I'm hoping I'm pushing you in that direction. If I want to learn more about SQL or Squirrel and I'm going to have a master link to all of this. Steve Gibson is the person who came up with this. He is the security now podcast and he likes to program in assembly language. His website has what information there is. There is a friendlier version at sqrl.pl. On the news group there is a diagram that has all of their gnarly bits if you are actually trying to implement something. And then that is my pin board page. User wonderful tag SQL that will have links to all of that and a bunch of other stuff. And that is really all I have to say. So I can either move on or any burning questions. I'm also blind here. That helps. No? All right. Thanks, Justin. All right. Thank you. So I'm up here today to talk to you about punch lines and silly hacks. And punch lines usually come from jokes. Here's the structure of a basic joke. You have the setup and you have the punch. So I'm going to tell you a joke. Here's my setup. It's a tweet I saw a few months ago from a quote says should array indices start at zero or one? My compromise of 0.5 was rejected without my thought the proper consideration. So this got me thinking, well, what happens when you actually try to use a 0.5 as an array index? Well, unfortunately it turns out it's actually not much. When you use an array index numerically Ruby calls absolute on it so 0.5 becomes zero, 1.5 becomes one. And that's not really fun. That's not our joke. So I decided I need to come up with a better punch line than this. This is a gem called array subindex. And what it does is it allows you to use floats as array indexes. Sounds like a great idea, doesn't it? No. Do not use this code in production. Do not even look at the code in the same room as your production servers. So that disclaimer out of the way. We go back to this code that we had before except we're acquiring this beautiful gem. And now we have our same array. And we're going to go after array index 0.5. And this time it does exactly what a sane person would expect it to do. It returns 1.5. And the clever person in the audience will note that that is half of array value zero, half of array value one added together. This makes sense to everybody except for programmers. The real world operates like this. Of course it doesn't stop there. We're not just going to do half Cs. We can do 0.25. We can do 1.001. It's going to take the appropriate adjacent values and add them together. But you know why do decimals have all the fun? We can pass in any valid ruby numeric class. We can do rationals. We can do big decimals. And let's say you're tired of numbers. Well, you can actually do arrays of strings. And it's going to take the pieces of the string and sit you together for things that don't divide evenly. It's going to go down. Oh, oh, it gets better. We can do arrays of arrays. We can do arrays of strings arrays of numbers. Arrays of hashes. And it still does exactly what you would expect. Okay, I'm going to stop now. Or else I'll go on forever. Because there's actually a real reason. Not just this to show you this to you. So why? Well, obviously I love standing in front of crowds. But to show that humor is a great way to teach complicated concepts. This hack I came up with, this gem, it's relying on Ruby's ability to reopen classes and change their guts. And this is a complicated thing for new Ruby programmers to understand. And doing it in a humor situation like this allows a new developer to look at a small kind of toy problem and figure out what it is than other than having to worry about like doing it in production and trying to figure out all the moving parts. There's very small, very few moving parts in these toy problems such as this. So it makes it really easy to digest. And the other really big reason why you want to do things like this is because they will make you a better developer because experimentation leads to writing better code. And for example, I've been programming Ruby for about seven years now. I wrote this gem a few months ago. I learned more about the Ruby array class writing this gem a few months ago than I had learned in all of the time before programming Ruby because I had to not only make my code do the fun part, but I had to make it compatible with everything else. So I had to read documentation. I looked at source. I looked at tests. I learned the differences between arrays in 187, 193, 20, 21, and it just taught me so much stuff that I would not have learned in production because you're never going to write code like that in production. You'd be crazy if you ever were. But in situations like this where it's a joke, you are freed up to do just whatever you want and it will expand your mind. Experimentation leads to better code and silly hacks are just experimentations with a punchline. So in conclusion, this is my call to action, write more silly hacks. Write more punchlines. But please never, ever, ever use that gem in production. Thank you. So I probably should have put my name on the board. I'm Andrew and I'm going to talk about Hugen, which is a system for building personal agents. I actually talked about it last year at this conference, but it's come a long way since then. So I wanted to show you guys. So it's open source, has an extensible Ruby API and over the last year we've gotten about 30 collaborators. There's lots of new features coming. We actually just released Rails 4.1 today. So in Hugen, events flow between agents and an event flow diagram. I'm just going to dive in and go quickly. So one task I might want to automate in my own life would be, hey, remind me to take an umbrella if it's going to rain tomorrow. So I'd make a new weather agent. I'd give it an API key and a location. I'd then make a trigger agent and I'd give it the path in the output JSON of the previous agent. In this case, it would be the conditions path, which can take any JSON expression. I'd give it a reg X of rain or storm. I'd feed that into a digest email agent, which just can bundle up a bunch of incoming events from a bunch of sources and send out a specific time, in this case, six in the morning. So when I check my email in the morning, if it's going to rain tomorrow, I have an email telling me to take an umbrella. So let's look at another example. Tell me when things I care about are happening. Well, that's kind of generic. But turns out the Twitter stream API is really awesome and gives you sub second response times on up to 400 keywords of things you care about. So let's put in some examples. So the Superbowl data announcement or gravity wave detected or Hugen open source. And I also have things like machine learning or Rails comp CFP. And then I feed that into a peak detector agent that you can give it a standard deviation over which you care about and which isn't perfect, but it works pretty well. And you feed that into an event forming formatting agent that just makes it clickable and finally into another digest email. And then you get peaks. So here's a hypothetical example for the gravity waves because I didn't have that one being watched. But this worked very well when the Rails comp CFP happened, I got an email within like five minutes. And it works on I have NASA Mars and a bunch of other terms that I care about listed and it works really well. So I get emails when something happens. We have a bunch of integration, SMS, location tracking, web hooks in and out, web scraping, sentiment analysis, public transit, you can run arbitrary JavaScript inside the agent, et cetera. There's a lot more. So here's location tracking. And then here's an example of this is a full agent. It's an extensible Ruby API. And I'm going to be ambitious and try to show you a live demo until I run out of time. So Hugen, we're going to actually make an RSS feed from Hacker News as if it didn't have one. So we're going to use a tool called Slector Gadget, which is a Chrome extension and bookmarklet that helps you make CSS selectors. You can install it like this. Once you've launched Slector Gadget, you select a region you care about. You reject things you don't want. Whoops, I do want that. I don't want that. It gives me a selector at the bottom. Copy that. I go into Hugen. I make a new this is going to be a Hacker News title agent. It just scrapes a website with CSS that I care about. So I paste it into these two places. I save that. Then I make a new RSS agent, which is an output agent. I tell it which JSON paths I care about, which are these and feeding it from the previous agent, the Hacker News titles. And here they are. So there's a feed of Hacker News from right now. And then let's say I wanted to filter it and only get news about, say, Ruby. So then I can make a trigger agent. I would tell it to receive data from the Hacker News titles feed. There it is. It shows me what those events will look like. I would go into the Reg X. I put a value like Ruby in this case and you could do other things besides Reg X. I give it a path. In this case, I care about the JSON path of title. I would save this and I'd re-network the agents and then I would only get things about Ruby. That's it. I give it the clicker. So first of all, mea culpa took me way too long, two years to get this done. I'm really sorry. I'm happy to apologize in more length when I'm not on a five minute deadline. Also want to say we upstreamed a lot of stuff from Tokaido into other parts of Ruby. So RVM Moveable actually was an upstream part of Tokaido. So it's pretty cool that we worked on a UI tool but there's a lot of stuff that actually helped other people. So let me just give you a demo. So I'm going to open Tokaido over here. It opened up. One of the things that happens when it boots up for the first time is it unpacks the Ruby but it will also automatically repatch your RB config if you install the command line tools in the meantime. First thing I'm going to do is I'm just going to say open and terminal. And open and terminal is basically just a thing that gives me isolated Ruby environment that's totally disconnected from what your environment's actually doing. So I'm just going to go and I'm going to make a new Rails app. I'm just going to make a new Rails app called MyApp. And this is all totally isolated so I didn't have to do anything on my system. My system doesn't have anything on it. In Ruby-V you can see what's going on. So I made a new Rails app and now let me go back to Tokaido. Let me add that Rails app in here. What did I call it? MyApp. So where am I? Ah, I'm in my own directory. So let me open my app over here. And then I'm going to just double click it which is going to run bundle install and boot the server. If I open this up and say open in browser I get a browser says myapp.tokai.do. Now let me do sort of the normal thing that you might want to do here which Rails G scaffold, article, title, string, body, text. Generate that. I'll run rake, db, migrate. And again all this is totally isolated. This is all you needed to get this working. And then if I go and reload the page if I go to articles I get my normal scaffolding I can say a new article, whatever. So this is kind of boring because we could do this five or ten years ago, whatever. So let me add discourse which is sort of a real application. So before I do that I'm going to actually open up postgres.app. So Tokai.do automatically integrates with postgres.app and I'm going to go to code, discourse which I already had checked out. It takes some time to run bundle install. And I'll say open in terminal and this gives me a new terminal with discourse. I'll just run bundle just so you can see that everything everything's working here. And then I'll say bundle, exec, rake, db, migrate and well I should say db setup, right? db setup and db db migrate actually it's going to fail. So actually what I need to do is I need to open up the redis server so I'll just open a new terminal and Tokai.do actually ships with some common stuff like that so you can say redis server over here and I'll rerun that command rake db setup and rake db migrate. I opened up the postgres app in the background there. So it runs all these migrations and then if I double click on this thing so remember discourse is a somewhat complicated and involved Rails application and part of the goal of this was to actually be able to do complicated and involved things with Tokai.do so now we've booted the server and if I say open in browser I get discourse.tokai.do here just like I had my app over before and discourse first boot takes a few seconds. So I'm here if I click login just to show that this is not a gimmick. This is sort of the blog in 15 minutes demo of 2014. I'm not gonna save an account, reload the page and now I can say create a new topic. So my god, so my god I am on stage. Discourse has rules you have to you can't just say small things. I am on stage at RailsConf, right? Create a topic, makes a thing, it's here. So the TLDR here is just we wanted to build something that actually would be useful for real applications actually uses the terminal can integrate with the command line tools but also integrates well with things like Postgres.app and connects to Redis. So that's awesome. If you wanna check it out it's released here. It's github.tokai.do slash Tokai.do app and you can just download over here and install it and file bugs and let's make it better. Thanks. Thank you. Okay my name's Ryan Alley I have social mediums. I work at Fan Gamer. We have a humble model that came out like five hours ago so that's cool. But now I'm gonna talk about something completely useless. So we're gonna build a Rails app in a single file because we can. And I call it reverse archeology through Ruby Golf because we're gonna be learning a little bit about Rails through the minimum number of lines. So of course obviously don't try this at work. Rails is all about convention over configuration and this is not that. But the thing is that a lot of people seem to say that Rails is this big giant monolithic app that does style Shodfront on high in order to get you with this restful thing like no you can totally use the Rails modules independently. So we're just gonna start with a basic rack app. And so that's rack. Pretty simple, right? You just block, you can turn on the path and you just return a special array that has your tuple of the status, the headers, and the body. And so all you need to add is just the roots, the controllers, the views, and melt everything else. So let's add the everything else. You can add the action pack, add your dispatch and add your route sets and create your routes. And if you notice the routes look exactly like Rails routes just like your routes.rb file including the point where you have the main page controller with the index and show file. And so let's make our main page controller. It's a basic Ruby object. We don't need to include anything, right? But here's the thing though, with these when it comes to Rails routes, like it needs to create a class method called action that has the method in a string, right? And requires a block. So you put that in the block. That doesn't look very Rails like. So, I mean, let's just make it look like Rails, right? So you reflect and create a new instance of itself and use the block methods to be able to do so. And then you have that. And of course that looks nice, but that still doesn't look very Rails like. But hey, it can be done in one file. One thing you can do is you can probably include the Rails metal, which is basically just a rack abstraction, right? So you can just include the response body. If you want to, if you want to change the status, you can do so. The status always assumes that it's HTML and the status is 202 unless you technically say so, right? And then at the bottom there, all you gotta do is just say run routes and that's it. That's a Rails app in like 25 lines. And you're done. Of course that's it. But of course you wanna do more things. Of course that doesn't, not very nice and neat. So if you wanted to add your stack traces or you wanna do sprockets, like you can do that in a middleware. If you wanna do more of the more basic things, you can include all your callbacks, redirects, your Rails helpers. That's already, you can always include that if you want to. If you want templates, well just use templates directly straight up. I mean that's the first option. If you wanna do templates, your own sort of templating engine, you can just include some of the rendering helpers and do that. And one thing that's really interesting about this is that if you're trying to do your own template engine, that's a good way to start and good place to look. Cause you're saying nothing about, okay I wanna do something from mustache or liquid or something like that. You don't have to do render text. You can create your own renderer if you feel like. Of course if you want action view and you can include action view, all you gotta do is just tell it where your views are. Or you wanna include all the things. Just do include action controller base and make sure you still gotta tell it where your views are. But that's it, right? And that's still the exact same config rackup file we started with and we're basically ending with. That's still 25 lines. A single Rails app in 25 lines. And that's the bare essentials for a Rails app to go from request to response. So I hope this slide needs to show either module Rails internals or inspired you on your next thin-sized mini app. And if you wanna stalk me, you know that's how you can do so. So my name is Adam Cuppey. I'm a partner of a consultancy that specializes in test-driven development. Oh anyway. And Ruby on Rails. So something that we've encountered a decent amount of time is that whenever you're running a command as simple as like this to basically run your specs, basically you run into this kind of challenge where it becomes fairly cryptic. It's not really telling you everything you need to know about the important information when you are running your specs specifically. You know what I mean? It's giving you information about failures but the problem is it's not really an experience and we're an experienced company. So what I did is I put together a gem. I just lovingly called it Superstar Four Matters. But anyway it's a collection of four matters that are designed to provide a little bit more to the RSpec spec runner experience. Now I created just a set of just simple aliases on my computer but if you wanna go back, you can actually look up how you can run a four matter and specify that. The first four matter that I would like to show you is actually the Sandy Metz four matter. And basically what it does is, oh, yes I do. Wait, yes I do. Yes I do. Hold on, I'm sorry. Yes I do. No. Oh okay, yeah, I'm good. Yeah, okay, good. So basically it just gives me a little bit more feedback. Now another four matter that I was actually quite a big fan of was something that I really like to illustrate as the tender love four matter. And basically the way this four matter works is after your tests run, it actually opens up a picture of tender love. Thank you. The last former that I'd like to show you was actually inspired by a talk that we all heard just a little bit earlier. But again, you know this is something that's really important, you know really inspired and basically this was the DHH four matter. Just gonna run my suite. See the beautiful thing with this four matter if you didn't know it is actually it makes a call out to the DHH API and it actually runs the series again, randomly selecting text from DHH quotes. Now if you're interested in getting involved in this RSpec four matter project, oh I'm sorry that's still Aaron. You can actually do that, you can go to the superstar four matters coding zeal repository and you can add your own four matters. I'm looking forward to your poll requests. If you wanna find out any more information, well you can just, you can check us out online. Thank you guys. Thank you very much. Hi, this is my first RailsConf, it's also my first Lightning talk, it's also the first time I've had my incredibly vanilla name butchered. So I'm Mark, this is Mike. My pleasure. Like I said, first RailsConf, the talks have been enlightening, I've learned a lot and we've noticed some commonalities and we've distilled them down to a couple of tips for having a great RailsConf presentation. So let's take a look. First thing to do is to burn a ridiculous straw man. After you've done that, you can show some terrible code so we can all feel good about the terrible code that we've written. Something SOA, there's hexagons, that's what I got out of it. And promote a gem that you don't even use in production. So let's burn a ridiculous straw man. All right, so you probably have Jason services, actually you all have Jason services, we know that. So here's a response from a Jason service, it's got drugs. There's a particular drug object, it's got some attributes and similar drugs are embedded within. And you all do this to parse that data, you use Jason parse and you index into it with square brackets into the hashes and arrays therein. Nothing to go wrong there, of course. Wait, what's that? Yeah, here's what's gonna happen. No method error on a square brace for no class. So you see the bug here, similar isn't spelled right. And this is probably in your test. So who's gonna catch that? So what do the experts say? I'm gonna quote Gary Bernhardt, he reminds us never, never to use square brace on array or hash, always be fetching, always be fetching. James Colgan says the same thing, let's just alias and be done with it. All right, so we're gonna do what the experts say, we take that stuff we had earlier and just put a chain of fetches instead. That's better, right? Yeah. Well, I mean, it's a little bit better to tell the truth. When this blows up, at least you have the line number so you know which one failed when you, we actually have a solution. And a hexagon. So let's do away with the primitive data structures. Don't use them. So what was once a Jason parse with square brace chain becomes fetching from JSON. Give it the JSON and now you have method syntax and you can use square braces and arrays, but it is checking the length for you, so you can't roll over. Or we also provide a conversion function that accepts any object that responds to two hash or two array and it, like such as a hash or an array or a party response. So you get the same data structure and what this is doing underneath for a hash like object is just defining those methods right away. So your error message has become usable. Yep, so what was once undefined methods where brace for no class is now no method error, see him or drugs not found and showing us what we actually had. So now we can see exactly where the mistake was. So in conclusion, why would you use this? We have strict key checking on hash based objects, strict bounds checking for array objects, error messages with the complete context. So now you can see exactly what the problem is and lazy deep instantiation, a lot of other value object libraries don't go deep. They're real flat. So array for science, recursion. Thank you. If you want to look at the gem, it's cover my meds slash fetching gem. If you don't want to use it, I don't care, that's fine. Just stop using square braces. Like I said, I'm Mark. I'm Mike. We're from cover my meds, we're hiring. Look us up on we work remotely. Thanks. Hello, my name is Trevor Yersh. I am with Zeal. Please stand up for a mid lightning talk stretch. Yes, that is stolen directly from the Ben Orenstein school of giving talks. I don't know if you guys saw that last year. It was pretty awesome. It rails Conf is like the most interactive awesome talk ever. And you guys all kind of look like this one here right now. So it's like, oh gosh. And then you smile because it's funny. Yeah, there you go. All right. Anyways, so Adam, I'm pretty long winded as you can already tell. And so he dared me to try and not use the five minutes and especially don't make Yvonne tell me to be done. So I'm going to go through this quickly and you will not laugh anymore from this point forward. Can't waste it on laughter. So I'm here to talk about company culture. Thank you. Company culture. Yeah, so it's made up of basically the way that we see it. I'm sorry, I'm going to, let's see. Uh-oh, yep, that's awesome. Great, I'm just going to go ahead and skip ahead. So company culture. So it's made up of three key elements, four key elements, three of which are experience. And we're a very experience driven company. We love to share, define the roles that are involved in the company experience and share passion, excitement, make it unreal. Like exceed the expectation. That's everything we, what we try and do with our people, our team members, with our clients, customers, users, whichever the role may be. Grow. So like create an environment in which your people can grow. And again, I'm going to go ahead and skip a lot of the details, but I'd love to talk afterwards about how we achieve these things in our company. And if you've got some ideas of your own, that would be awesome. We use multi-discipline pairing, all kinds of cool things in order to grow our team. Collaboration. So contribution, pair programming, yada, yada, yada, communicating meals, end of day show and tells, things like that, in which we create a lot of collaboration amongst our team. Time flies, Evan, time flies. I know, I know. Just go. Don't tell me, I'm up there the whole time. The most important thing that we've found though, is to, is to, is it going, is it gonna go? Yeah. There we go. Is to work really hard to empower our people. And we do that by, we create tools and processes that empower our team members to be able to solve problems and serve clients or build product. We allow our team members to own parts of the experience, right? So they're like the champion of, you know, this part of the experience, whatever it may be. We keep the roles tidy and the list short, meaning it's really important that people know exactly what their role is in the company. And also that you keep that list attainable, you know, that backlog of things that they're supposed to keep up, keep doing, above and beyond the day to day, right? And so keeping that list short, keeping the roles tidy, these are very important in making people feel good about themselves at the end of the day and when that accountability time comes. And let's see, so promote your people, send them to conferences, get them involved in talks, get them involved in open, you know, open source projects, those types of things. Get your people out there. And let's see, so have awesome gear, things that like help your people sort of bond under an umbrella that they're proud of, something that they wanna go out and share with the world and become an ambassador for your company. And be transparent, like death to the black box, right? Get, encourage your people to sound an alarm when something feels like a black box, right? So like essentially turn your company sort of like open source your business with your people so that they feel like they're part of it, they understand it, and that they can call BS, bullshit, when they need to. And then respond to that, right? So as a result, we found as a company, like we sort of are a flat-ish company. I'm not here to preach the flat model, but we found that by practicing and focusing on these four principles, we became flat-esque. So bye, thank you. Thank you. Hey. Hey. Thank you very much. Thank you. And thank you, Spotlights, for making it so I can't actually see the audience, who I'm very grateful is slightly inebriated after coming from Happy Hour. Today, gotta love screen blinking. On Tuesday and Wednesday, we've had some great sessions about distributed systems and service-oriented architectures and big rails. One of the questions that was asked in one of the sessions was, how do you handle failures? What can go wrong? And there wasn't really enough time to address it, so that's what I wanted to do in my lightning talk. By the way, my name is Mike Burgess. I currently work for a publishing company called Deseret Book in Salt Lake City. In the past, I've also worked with many other types of distributed systems besides rails apps, like luxury home theaters, automation systems for home automation. All of these things are distributed systems, and all of them apply to what we're learning about with our rails applications. So first of all, I wanna talk about when distributed systems go wrong. A few years ago, I was signing up for Internet Service Access. You all know who this company is, it shall not be named. It's a big cable monopoly in half the country. I signed up for automated billing on my credit card. Everything on the web looked good, everything on the customer service looked good, yet for three straight months, I kept getting billing notices that had a higher and higher balance, saying that I wasn't paying my bills, but every time on the back of that billing notice, it said, you're set up for direct debit, don't send payment, it's all taken care of. So what's going on here? We have two separate distributed systems. We have a system A, that's the web system, the customer service system. That said, your billing's all good, you're set up to go. System B was the actual billing system. Somehow it didn't get the message from system A. So when money's at stake, if your systems aren't talking to each other, things can go horribly wrong. This is an area where software riders can learn from software engineers. The reason for that is engineers study failure. So if you're writing your own application in Rails or any other system, you want to take a look at what can fail at each step of the process. If you have an HTTP request that fails, users are going to have to retry. HTTP response fails, but the request was successful. Sometimes you might have the user retry, but the server actually already did the thing, so you need to consider that. In your backend systems, you might have distributed job processing. If your job queue misses a job event, then you need to figure out a way of making sure those jobs don't get dropped from the queue. And finally, user notification at the completion of a job. If your user doesn't receive their notification, you have to consider what happens in that scenario. So how do you survive the failure of your distributed systems? You need to make sure that each action that your system can take is repeatable, or adempotent, which I am sure I mispronounced. You need, you can use unique request identifiers to ensure that's the case. When a request fails, you can use exponential retry to account for network congestion. You can use persistent queues in your internal systems that will store your jobs and retry them if they fail. You also want to have background monitoring systems that look for orphaned jobs, as well as occasionally validate your systems to make sure that the data that's in each system corresponds with each other's system. Any of these, several of these solutions would have solved my ISP billing problem without having to walk into the customer service center and have it fixed manually. So how do you apply this in your own applications? You consider each piece of a system, ask how it can fail, and who will be affected by it, and then figure out the right way to respond. In the case of a failure of a user request, like I said, they just have to click Reload on their browser. Internal failures you want to handle automatically so that the user experience is as smooth as possible. And if we take these engineering principles and apply them to our software writing, then we can write code on distributed systems as software writers and software engineers working together without fear. Once again, my name is Mike Burgess. You can find more information about my projects at those locations. Thank you for your time. Well, hello, my name is Gustavo Robles. I come from Crowd Interactive in Mexico. And we at Crowd have this little process that whenever one of us sends or submits a pull request, two other guys have to actually review it to see that everything is cool. So we used to do this the old way, like going actually on GitHub and find a repo, find the pull request and then comment there and see if it was all okay. But some guys at the office decided to build this app, this pull request dashboard. And what is pull request dashboard? Well, it's a single-page app built for Ruby 2.1 and Ember. And basically, you get to see all your pull requests so you can review in there, merge there and so we can make everything quicker. Why we decided to build it? Well, we decided to build it because it takes more time to actually review all the coding in GitHub. So we needed to do things faster because time is money. So that's the address and I would like to have a quick demo. Okay, not that, I think, wait, that's it. Okay, so you have to actually log in and quit GitHub. And once you log in, it pulls all your information on. You get to see your private repos, your public repos or all your repos and I already created a pull request for demo purposes. It's a public repo called PR dashboard and you get to search for not only one but any other repo and you will see like every single pull request is there. And you can click here, review and you'll see all the changes there and you have these quick buttons to close the pull request, to merge it, to add the classic looks good to me comment or actually go and see the files in GitHub. So once you click on look good to me, well, you'll see that there's a comment now by me and I can merge the pull request as well. It will be already merged. So this made all the pull request like faster all the reviewing process for us and it's open sourced. So I would like to invite you guys to help us contribute, make this app better and this is the URL. So feel free to send your pull request. We will review it and we'll make this better. Hopefully with your help. Thanks. Hi guys. I work as in crowd track as well. My name is Hector or you can find me as like Booma and the social networks GitHub or whatever. And last week we were like talking at the office just hanging around and we were talking about what if we have this dashboard to see the contributions that we make to the open source and I said, why not? So we built this thing. Well, I built this thing in a couple of nights last week. It is still in beta. I have a couple of bugs. So basically I create this dashboard where you can see all the contributions of all the members of the organization that you select. So it's pretty cool. So basically you log in with GitHub, you click in the big octocut there and then I will fetch your organizations. Then you will select one of those. Then I will get all the members of your organization. Then I'm gonna look through all the repositories that that specific member has or all the members have and then I'm gonna check if they have a fork on one of those repositories and then I'm gonna check if they have, I'm gonna fetch all the pull requests of that fork and then I'm gonna check if you have one pull request in that specific fork. That's pretty much the result. You have your open pull request, your closet pull request and the repositories that you have been contributing. You will get this kind of rank where you can see who is the top contributor of the organization and I'm using the GitHub gem to connect to the GitHub ABI psychic because I will explain a little bit about why I'm using psychic and of course redis and I'm doing in Heroku because one of the main goals is to make it free. So it was kind of hard because in Heroku you only have 30 seconds request time and if you use a worker, you have to pay like $30 per month and you only have 500 megabytes in that specific worker so it's a pain in the ass. So after digging a little bit and doing this, I create two Heroku instances. One with just one web dyno. The only one, it's only a worker and basically you start, you create those instances and then you do this rating. Basically you set both as zero, the web and the work dyno and the work dyno as zero. Then in the instance that you want to have to be the web application, you set the web as one and then in the worker, sorry, it's one here, it's typo. And then you do that. First you have to set a zero both. If you're not, Heroku's gonna charge you. So we don't want that. It's gonna be, we want it free. After that, we have to point the first, the worker instance to our radius to go free configuration that we have in the main application. That's pretty simple. You only do Heroku config that Heroku config. Well, you will see, it's real simple. And then there came another issue that in Heroku you only have limited database connections. So it's kind of hard. So we have this tool, remember that URL. You go here, you set how many workers, how many dyno do you have. And that's, it makes some calculations and you can set up that configuration in your application. Then you deploy both. It is hosted in contributron.herokuapp.com. I want to say thank you to the guy who designed the logo. And I'm using, I am the beta for Skyline, but it is flat as a pancake because I don't have any requests. So please go ahead. And if you find some bug, let me know and I will fix it. Thanks. Thank you very much. Hi guys, how are you? Hey, well, I am Victor. I came from Mexico. I work at Crowd Interactive. I'm a software engineer there. We are a commerce consultancy firm. So I just came here just to tell you how I enjoy this and how I can want that you share everything and I want to share you. So first of all, I will talk about Mexico. This is, we have delicious tacos there. We have tequila. And we have the other part. We have, well, developed parts. So, but I try to push hard to make the connection with them because it's kind of hard to do it like, to talk with us and talk with them. So, therefore we do, we are like handling how to push them to have that. So, we create this community is Rails.mx. We are right now like 300 people and it's growing. Also girls in the company, they have their own community is codified us. So, and the other thing we have is magmakonf. So I just want to tell you how it's magmakonf. This is magmakonf. We use tools, techniques and experience about software development. And just go, we want doing this conference just for Ruby and Rails. But now we are also getting allowed to other technologies, well, web development like JavaScript and everything else. And this magmakonf is not a regular conf. Welcome to Manzanillo, it's a beach. It's there in this small spot. We have the magma village. It's like 15 beach houses. Like this one, where you can hang out with other attendees and speakers. I told somebody else, it's very good because you can hang out with everyone because almost all the people stay there. You can go swim and super cool. You can play soccer, play music because we bring all these acoustic instruments. It's six minutes from the venue. And also we have the live real Lucha Libre, like this one. This was the last year. We invited a guy from Hatch Rocket who was fighting there as well. It was nice. They're from GitHub. And also we have great parties. Tequila, you see. We have a boat party as well. Konstantin Hassa and me dancing Gangnam Style. So you're wondering who is the people who attend this conference? Well, we have there before Brian Lyles, Scott Chacon, Santiago Pasarino, Greg Pollack, Konstantin Hassa, and also tender love. So it's time to wear your mask. Are you ready? Thank you. Thank you. Thank you very much. So I'm gonna be asking you a whole bunch of questions and all of them are rhetorical except for one of them. And they're rhetorical because these are things that you probably should have asked yourself already. And if you haven't, you should start thinking about them and that's what this talk is about. So the first question, which isn't rhetorical is what sets great companies apart? And I actually want an answer. Anyone? Yeah? Culture sets great companies apart. What sets great companies apart from a customer perspective? Two good things. Kind of what? Working code. Working code, yeah. And all of these play into what I say sets companies apart and that is their disasters or more specifically what they do when they have a disaster. And the questions that are about to ask, which are all rhetorical, are what do you do when you handle your disasters? But first, I wanna talk about you because you are awesome. It's true. There's one problem. You're human and that means you're fallible, which wouldn't be so bad except that because you're human you have an ego and this ego makes you think that you're really not that bad. But we are and we are all going to make mistakes. And if you can embrace these truths, you can make your customers love you. And with that in mind, your app is going to break and your app is going to break badly or maybe just annoyingly, but it's going to do either of those at the worst possible moment. And you need to be able to answer some simple questions when it does, like who? Who do you call when the signup form is broken? Who do you call when it's a database error? Who do you call when something's going horribly wrong with the CSS and submit button it's hiding itself underneath the logo for no apparent reason? And who do you call it 4 a.m. when the site is down? And who do you call it 4 a.m. when the site isn't down but you can't charge anyone's card? And then there's what I call the secretary test which you should be able to pass. Imagine that you have a new secretary and she and I say she because obviously men are incapable of rising to the challenges of the secretarial job. That's why they're all stepped by women. Now she started last week but she doesn't know anyone at your company and she finds a major bug at 4 a.m. Why she's working at 4 a.m. in her first week I don't want to know. But you should tell her not to. And should she call someone and who should she call? And what should you do if that call comes in? Do you wake the CEO? Do you wake your customers? Do you write a post explaining what's going on? And where do you put that post? And do you even have access to it? And where do you go to coordinate the bug fix at 4 a.m. Do you go into a chat room? And if so, which one? And do you get onto a conference call? And if so, which one? And you know what number? And how do you know how severe the problem is because the severity of a problem affects the response that you're going to have. And how do your workers communicate during an incident? And how does the CEO who you woke up at 4 a.m. two hours ago get an update about what's going on? And if you've got the fix ready? And how do you know if you're really done fixing it? And how do you know if your fix is safe? And how do you keep making smart decisions when you're seven hours into an oh my fucking God bug that started at 4 a.m.? And how do you make sure it doesn't happen again? And how do you make sure you handle the next incident better than you handled this one? And how do you reinstill confidence in your clients when they just saw your site go down badly at the worst possible moment? And how do you know what other questions you should be asking? And I put it to you that you should go to a website called gracefuldisasters.com, which is an open source project to answer these questions. It's markdown documentation. It's a template for your group or company to fill in the blanks almost literally on how to do this and have a process for handling these issues and for making sure that the next time you handle them, they're better. That's it. How many people have heard of Docker? So keep your hands up for a second if you would. How many people have installed Docker? And how many people are using it in production? We gotta buy this guy a beer. So I'm giving you the beginner's guide to Docker and you might have thought the beginner guide is about you, but really it's about me, right? I'm kind of a beginner with Docker, but I see a lot of potential. I want to kind of get people up to date on that. With Docker, everyone is a beginner because it was only released as open source in March of 2013. And it hasn't even yet reached version one, but maybe it is ready for production. Because Spotify is now using Docker containers in production and by due, the Chinese version of Google is using 500,000 containers to run their site. That's crazy. That's a lot of containers. As well, it's supported in OpenStack and AWS just announced this week that they are supporting Docker. But what is Docker? So a lot of people have heard of it already. Docker stands on the shoulders of giants. It is not a virtual machine. It is instead a Linux container. It allows you to have a clean namespace container. It gives you a lightweight thing that you can pass around. One of the key concepts in Docker is images versus containers. You use images to build containers. This is the key thing I wanted to get to and the reason I decided to give this talk was the use cases. As I've been going around the RailsConf hearing a lot about hexagons and service-oriented architecture. And one of the things is how do you set these up? A lot of people are talking about Faker, about VCR and whatnot. One of the other ways you can do it is use a vagrant virtual machine that supports Docker. Use Docker containers to play the part of all of your other services. And now you can actually test the thing that you're working on. They boot in about a quarter of a second. They have their own IP stack and they can be linked. Another great use case, and this is probably the one that we use the most, is database images. We have some fairly large databases and a lot of times with a bug you want to be able to use the production, not production data, but a representation of production data. Maybe it's a bug based on the data. So you might have a Jenkins job go off in the middle of the night, does a PG dump, and then a second job that loads that PG dump file into a Docker container. If you think that the containers and the images, sorry, it does not load them into a container, it loads them into an image. Think of the images as a stack of Post-it notes. Now when a developer comes along, needs to troubleshoot a bug, they can pull the top Post-it note off, which is your Postgres data already loaded in. As they troubleshoot it, they find the bug, they fix it, whatever, you now throw that one away and pull another one off the top of the stack of Post-it notes. Another great use case is testing your app against different versions. For example, looking at moving to Ruby 2.1 or whatever the next one is, you can now have a container that includes Ruby 2.1 and then run your tests against Ruby 2.2 or different versions of Postgres. Another use is for static files, your JavaScript whatnot, or you may have image files that your site requires. One of the tips that I do recommend is one process per container. I've seen a lot of sites and blog entries that say, you can use system D to get multiple processes in a container, but it's not a VM. You don't run your entire app and all of its requirements. Do use Docker files. They like Chef recipes or vagrant files and they allow you to have repeatable results. For those that have used it, consider the order of your Docker file. The stable things going first allows you to take advantage of the caching and add may not work the way you expect. You can only add files that are below your current directory. And the final thing is when you're starting out, start in an empty directory. If you start in a directory that has a lot of files, it will say Uploading Content. It's creating a tar of all the files below. It takes a lot of time. You don't want to waste them. That's it. Thank you very much and go right ahead. Thank you. Hi, everyone. I'm here to talk to you about something that is not very glamorous, but you have to do it sometimes and it can be a pain. So this is about two kinds of data flows. We have a push flow and a pull flow. When you integrate with partners that you're dealing with getting data from, you ideally want to tell them, just integrate with our API and then you can just sit back and the data comes in. It's like water pressure. So you just let it come in and it's great. On the other hand, sometimes you need to go and you need to get the data. So this is kind of like a vacuum. It doesn't flow. It sucks. It's different every time because you're dealing with different kinds of data and it can come from different sources. It might be a file. It could be an HTTP endpoint. It could be an FTP mailbox, maybe email. It comes packaged differently. Sometimes it's CSV or it's XML or it's JSON. Who knows what it is, right? And then of course you have your app domain and it, I'm sorry about that slide. There's a little vegetables down there and your data can, of course it doesn't match your own formats. So you have your own attributes. The data comes in differently. Date formats perhaps are different and they're not so easy to parse. So you have to deal with that stuff. But do we have to reinvent the wheel every time? I think maybe not. Maybe there's some common patterns here. If we can break it down maybe and come up with a Ruby DSL for this. So ideally we want to get to this point where you have a single interface for all the data that's coming to you. You just want to call process on it and get it. So I built something called Stockboy and we use this in production. You can get, you can declare where you get your data from. So you can say it comes from a file. You tell it what directory, how to pick which file to get. That last for example might be the last file in the directory or you can pass in a lambda there and say give me that one. You can use FTP, same thing. You can use IMAP email. You can use this thing called SOAP, which is great. You might have other ways of getting data. I don't know. Maybe you can write me a plugin or something. You can get the data and then how do you read it? So it might come in as CSV. It comes in as XML, other things. And then you say how, you know, like how do we shape the data now? So we can map it. So for example, you know, the names that come in are different. You might wanna say something like this. You might wanna say format it as a time or whatever it comes as. Again, lambdas. You can chain these things together. Combo moves. So you can say take two fields and add them together. You can, if your fields match up perfectly, you just gotta name the attributes and you're done. That's it. Combine all of that above and you come up with something like this where you just name them and convert them. Then there's filters. So you can then say, well, if it's missing email, we're not really interested, just put that over there. Again, you can look at the input values, the output values, map it all together. So what do you actually get out of this? So your data workflow becomes configuration. You don't have to define these things using real code. This becomes a file. You can put them all into config directory and you can have a lot of them and they can all be different and you end up with this. So you can have an XML file that comes over FTP. You just define it like this. It loads up. You can have a CSV file that comes over IMAP. You define it in your file, load it like this and then you end up with a way to process over your records. You can then go over each row and say what you want to do with it based on how you filtered it. Is it something we want to keep? Is it something we want to drop? Is there different things we want to do with it based on the filters? And you end up with this kind of situation where you define where it comes from, how it's packaged and what you want to turn into. So you get a little helicopter and stuff. Many sources, one interface. Sometimes you have to do this and we solve these kind of problems and maybe you do too sometimes. So go check it out. And my name's Andrew Vitt. I work at Guest Folio in Whistler, British Columbia. And thank you, everyone. Thank you very much. Okay, so I'm gonna talk about magic today and if everybody knows magic, you actually have to save the word for it to work, right? So when the magic word comes up and I'll cue you, I need everybody in the audience to yell really loud the magic word. So I'm Brian Garcide. I'm mostly a designer, but I know enough rails to pull my gets and rake my DBs. I'm a manager of web experience at the Infotech Research Group in London, Ontario. And just like every other company in the world we're hiring, what's cool though, we just recently bought the Masonic Temple in Toronto and turned it into a really cool space. So if you're interested in working in a cool place in Toronto, come talk to me. One of the neat things that we've done at Infotech recently is we broke down walls. We broke down walls between BAs in the business. We broke down walls between developers and designers. And we changed the fundamental thing which is we no longer say that's a styling issue and just throw it over to the developers. We're trying to turn developers into designers and designers into developers. The first way we did that is by getting them together and bringing them together in a little team. I'm a designer primarily. I've drawn my entire life and I know that drawing is a superpower because it shortcuts the communication channels. If I can draw you a quick sketch of what I want it's a lot easier for you to build it. So we created a team called Team Awesome. And Team Awesome was a cross-functional team. It was designers and developers and once a week we got together and we had this little soiree where one of the people, and it rotated every week would come up with a design challenge and then would lead the team on some discussion of design. What is a good design? So my favorite one and the one that I started out with was the squiggle. So what you do is you take a squiggle and you have to really quickly look at that squiggle and in about two minutes come up with a drawing out of that squiggle. So whatever that looks like to you you turn it into a drawing. You tell a little story about it and what really frustrated me was three quarters of the team and remember half the team is designers said I can't draw. So I told them a magic word and this magic word is gonna work for every one of you. It's gonna turn every developer in this room into a designer. So on the count of three when you see the magic word I want you to say it real loud. One, two, three. Bullshit. That's right, bullshit. And why is this bullshit? This is my son, he's five years old. He wakes up every morning at 7 a.m. and shrouds himself in a blanket to protect himself from the cold Canadian winters. He sits there and draws and he draws a ton. And this is one of his drawings. Now his anatomy is not great. His circles are not perfectly circle. His feet are a little janky but you know what I've never once heard him tell me? Never once heard him tell me I can't draw. This is my daughter, she's eight years old and one day she broke my heart. She came up to me and said, Daddy, I don't wanna draw with you on Max anymore because I can't draw. So you know what I said to her? No, I'd be a horrible father if I said bullshit to my eight year old daughter. Of course I didn't. I told her, of course you can draw. Everyone can draw. Drawing isn't a skill that you're granted from God. It is something that you just develop and the way that you develop it is by doing it more and it's a superpower. So who doesn't want a superpower? Oh, I'd pop my peas and I'm a broadcaster, I should know better. So all it takes is time and an open mind. So everyone sat at their squiggle and some of them struggled a little more than others and some of them did really good things and they all had great stories at the end of it and they told us little stories of what their squiggle looked like to them. So I just threw together a quick little squiggle. That's what mine looked like to me. And it's also kind of emblematic of what I'm trying to say here. We're not the stories that we tell ourselves. We're not the scripts that we run in our head. We're not, I can't draw. We're, I'm not great at drawing but you know what, tomorrow I'll be a little bit better because I guarantee every one of us in this room couldn't code at some point in their life. And it's not like a light came down and shone upon you and suddenly you could code. It's because you sat there and you worked on it and you developed a superpower of coding and you can develop the same superpower of drawing. And the only thing that's stopping you is bullshit. Thanks guys. So that's me. Just a little last thing. My friends and I have built a little app. It's a billing platform and we've developed, we're working on an API right now so that you can tie all of your cool apps into it and start to get built for them. It's not like Stripe, it's actually sending out invoices and stuff so a little bit different. So check that out too. Thanks a lot. All right, so I am Mike Verrata Stone and I am going to probably have that Let Me Code song stuck in my head for about a week or so. You can sing it now if you want. I'd like to but I don't think I can do it as well. Bullshit. So I'm here to talk about Engine Extra. Just a quick show of hands. How many of you use Engine X? Awesome. Last night just to prepare you out of gaming pretty late so shout out to all the werewolves and magic players and whatnot. So I did this pretty quickly so if you wanna check Twitter I wouldn't blame you. So what is Engine Extra and why should I use it or why should you use it I guess? So let's look at GitHub read me and find out. Oops, sorry Farah about that. I will try to fix that as soon as possible. So first what is Engine X itself? It's an efficient web server. It compiles all the modules into it rather than like Apache where you compile the modules separately and it has a clean and consistent configuration. So and it has much more which many of you know. So then what is Engine Extra? It wraps Engine X source in a gem. It is an intuitive Ruby DSL to configure Engine X and it's one place for configuration and compilation options. It also auto compiles for you just in time and it breaks a common config out to partials. It translates existing Engine X config to Engine Extra DSL so if you wanna get started with this pretty quickly you can and it has some start, stop, status and other actions you can use through the gem. And I've been working on this for a while and it has as you can see a lot of the versions for Engine X the version numbers match Engine X so it's pretty easy to figure out which one you might wanna use. Although I've only been doing the stable versions of Engine X and I just pushed today the current 1.6.0 version of Engine X which was released today as far as I could tell. So let's see some code. So if you have your enginex.conf which is just a simple one right here. You can say engine extra convert and it will create your engineextra.conf.rb which you can place in your directly in the directory you wanna run it from or in a config directory if you wanna put it in your Rails config directory. It pulls the compilation options from your existing Engine X binary so it will know how to use what you're already using and then here's what the configuration looks like. It's just pretty much straight one-to-one mapping between the two just do ends instead of braces although if you prefer braces you could probably do that. So that's that. So I'm gonna do my cheat sheet a little bit here real quick. So let's look at, so I got rid of all the compilation options because it was basically the default Engine X and here we go with a simple configuration. You can start it and I had it open on port one, two, three, four, five and here we go. It's just some static server serving a couple of static files. And so that's that and I can also do engineextra status which will show me that the server is running. Engineextra stop. And then engineextra status again, see that it stopped. And engineextra print will print your enginex configuration that will be generated. And partials just really wanna, if I have my stuff broken out into partials I can say static site, load my specify where to load my partials and then partials directory enginex.comp is the file we wanna load. There it is. And that had three servers. So now all three sites are loaded using the same thing and that's almost it. So if you wanna help, I have a GitHub account with this setup and I'd love to work with you on more ideas if this rings true to you and that's pretty much it. Thank you very much. Cool. My name is Kiyoto and today I'm gonna talk about Fluendee open source project that I'm a maintainer of. So I don't know why this thing is going ahead on the cursive using Windows. So can I get a quick show of hands? How many people know Fluendee? Awesome. You guys don't have to lie, but I see like two hands going up. So, and that's why I'm here. And over the past like three days this is my first RailsConf and I've been asking people like, hey, do you guys know Fluendee? No. What is it? It's like a log management thing, data collector and everyone's like, is it like New Relic? And it is not. And I was like, you know, fuck it. I'm not gonna rely on my language. I'm gonna rely on diagrams. So in many organizations, this is what your data pipeline looks like. If you're like data engineer, you probably find this kind of familiar. I worked in finance basically doing algorithm trading. I ran into this problem all the time. Like basically there were like 20 scripts written by 40 people, like 15 of them are fired because it's finance and you have no idea how your data is coming. And this sucks. And what I call this like M times N problem because they're M data sources, they're N places you wanna shove your data into. Hopefully it has real time as possible and it's never the case. And Fluendee fixes that. So that's what it is. And this seems to get understood better. But still I'm like a maintainer slash community manager. So I tried to give a laundry list of stuff. But one of the things about me is I have terrible memory. And so if I tried to repeat the same line twice, I'm gonna give like three versions of it. So here's a little mnemonic that I came up. And it's not like this, but more like that. It's written in Ruby, actually the core program is only like 5,000 lines of Ruby. It's open in terms of of course open source, about 2.0 licensed, but also has very open architecture. So you can write your plugin when like anywhere between like 30 and 200 lines of Ruby code. And people have done that. There are about 200 plugins out there covering pretty much any kind of data storage system and a lot of like input sources. And I wasn't that familiar with many like functionalities of Ruby before I became a maintainer. But in my day-to-day duty of answering a lot of questions on the mailing list, I became pretty good at Ruby. So this like don't be afraid even if you're not that familiar with Ruby. And if you're like Ruby expert, I'm pretty sure like a lot of you are. It's actually very easy to get started. And yeah, so those plugins give you a lot of flexibility and it's super lightweight. Consumes anywhere between like 10 to 20 megabytes of memory. And there are some alternative law collectors, but they tend to be pretty heavy handed. So it's easy to get started. So the other thing, who uses it? Nobody wants to be a guinea pig. So like from this point on, it's gonna be pretty much a brag alert. So Nintendo apparently for their video games, especially for online game data collection. The other one, and they are the big users, Slideshare, they install it on 500 servers, I heard. And you can learn more about their writeup at that bit.ly URL. And even more brag alerts, who is this guy? Yes, he's like the most famous Japanese person alive in this room probably. He's not here, right? And here's his code. I didn't touch this. I would have touched it if I, if it wasn't like, you know, euphoric enough, but it's as good as it gets. Fluently proves you can achieve program of happiness and performance at the same time. And a great example of Ruby beyond the web. And one testimonial is not enough, so here's another one. Who's this guy? I guess he's a little less famous. He's Adam Wiggins, the former CTO of Heroku. And he's very into this 12 factor app thing. And logs are streamed, not files. I love that Fluently puts this concept front and center with a developer-friendly approach for distributed systems logging. So that's pretty much it. Gemini install Fluently, you can get started really easy. We have like the usual web presences and you can also reach me at Kyoto Tamura which he got right. And a little shameless plug. I'll be speaking of MongoDB World, this summer, so if you happen to be a MongoDB user or go into the conference, I'll be looking forward to seeing you there too. Thanks a lot. Thank you very much. I guess this is my doubt.