 to talk to you briefly about some of the fun things I've been doing with teens in Lafayette. I'm the organizer for the Lafayette Tech Meetup. And last year we started running kids programming workshops. We call that program Lafayette. And I just wanted to talk to you about that today because we've had a lot of great support from this community. And then we've also found that using Ruby and Python have been a really great way to get kids into computing. So again, why teen hackathons? Well, it's fun. Our main goal is to get kids, to give kids that spark of interest in computing. We're not trying to replace something like DaVinci or G-School. It's really just to get to a community who maybe isn't always able to access computers. Our hackathons are held at the Lafayette Public Library. They're free. And you don't need to have a computer, although these days a lot of kids actually do. The teens come with their friends, or they make friends that night, and we have food. And then we also get a little physical with them, too. And I've got some pictures to show you that. So the two hackathons that we run this year, the first one was a Cypher scavenger hunt. The teens had to decode a couple of different texts. And then they had to do a scavenger hunt in the library along the way to then win. More recently we ran a games hackathon where we had the kids do a couple of different games. So like a guess my number game, roll the dice game. And then for the future, I personally would like to do a language analysis hackathon. So like sentiment analysis would be perfect there, a basic sentiment analysis. So we usually just use the Code Academy Labs website for the kids to use so we don't have to set up the environment. And it's actually really nice for that. We have them save their text in a text editor so then they don't lose their work. You can see some of the kids there. The teens will come and they form teams that night, and we find that that works really well. Usually they're paired or working in groups of three. And then we'll take breaks throughout the night and we'll play some really random games. This game called Evolution where I forget what you start off as but you kind of migrate up to like higher levels of existence. And then the big picture shows this game called Ninja which involved ninja chopping. Food's always a big part of our hackathons. The library has been great to sponsor that. And so we always have pizza and chips and other snacks and the kids really like that. We've been fortunate to get some nice swag from donors and the kids always love that. They love the t-shirts, the stickers. It's amazing. So they really appreciate that. And just to acknowledge the local sponsors and the people there who have helped us make this event possible, one final note before I leave. We had two teen girls who were programming in Ruby and when they were doing the Guess the Number game, one of the things they realized was they didn't have to ask their questions, their prompts in English. Their first language was Spanish. And one of the cool things that we saw was that they were so excited to then have their computer program writing silly things in Spanish. And so that was probably one of the highlights of our recent hackathon. So thank you. My name is Sara Horan. If you haven't done this yet, if you're in charge of any servers, go and upgrade Bash. Don't listen to my talk. There is this huge vulnerability about it and it's kind of like SQL injection, but for your shell. So that's fun. It's a little public service announcement. We're going to talk about how to make your database crazy fast, right? I'm with Honey Badger. We have a lot of data coming in, so we think a lot about the database a lot. And we kind of have trouble with this as Ruby is because computers are getting more and more awesome as time goes forward. And so we're able to use these cool abstractions, you know, like active record. But as our database load grows, we actually travel back in time. We have to deal with things that people dealt with 10 years ago, 15 years ago. And we're not really necessarily used to this. And so I'm going to go over a few of these items with you. The first thing is to make sure that your queries are fast. And for that you need to know explain. And I'm sure all you guys know about like explain, right? You put explain in front of a query in Postgres and you get an explanation of the query. But the good news is that you only need to know one thing about explain and that'll get you maybe 50% there. You need to know the rows line. This is telling you how many rows the database is going to have to look through in order to answer your question to run your query. And basically the number one rule is more rows, more problems. So I've got a little bit of homework for you. Go and run explain on count pagination queries, sorting queries for larger and smaller datasets. And you'll find that, well, basically these things don't really work that well in larger datasets. All right. So nobody wants to do that, right? This is a lot of hard work. This whole query optimization stuff, like can't I just like buy my way out of this whole? Yes you can. If you happen to be using a VPS and your database is slower than you would like, put it on a real computer. And that will probably solve your problem. And use lots of hard drives. This is a normal database server for us. You put the operating system, the logs, and the database on separate disks. The goal here is to just really optimize for disk IO. Also get a lot of RAM and tell your database how to use that RAM. This link here points to an article about PGTune, which is a great utility that inspects your database, I'm sorry, inspects your computer, and writes out a sensible configuration file to let you use all that cool RAM. Increase read-ahead. Linux has this cool feature called a read-ahead cache. It's set very low, but you can get a lot of performance by increasing that size. Increase your vacuuming rate. Make sure that your locks don't have locks on your locks. Use replicants for long and slow queries. You can actually have an identical second database, identical to your first database, and use that for all your expensive reporting. Use partitioning to split big tables into little tables, and then you can do things like delete old data or archive it. Move to an incremental backup system. And finally, come at me, bro. If you have any questions or anything, I'll give you a big hug, just like this little guy here, and we can talk about databases. If you're interested in learning more about this stuff, as you probably noticed, there are a lot of links in these slides. I'll be tweeting out a link to my slide deck and the place where you can get all these links in maybe an hour or two. All right, thanks. My name is Jessica Goulding. I didn't know I was doing this talk until about 30 minutes ago, so there are no slides. There's this website. And we'll talk about it in a minute. Show of hands. Anybody go to GoCode Colorado this past year? Anybody? One, two, one? All right, I'll take it. So GoCode Colorado is a hackathon, plus plus, is like what I would like to call it. It's an initiative put on by the Secretary of State and the Governor's Office. This is, we just did the first one last year and year two has just been announced. What I really like about it is it's an initiative that's taking data already from the Colorado Information Marketplace, that's based on Socrata's platform, and taking, they reached out to businesses and said, like, what are some of the problems you're having and how can we take the data we currently have and help you solve those? So we pulled a lot of business owners last fall, came up with about, I don't know, a hundred or so problems, brought it down to 25 and then down to five and announced them as far as under the challenges, and I'll show you later, or you can go there and check it out. And what we did then is had a hackathon that went on in five locations throughout Colorado, and they were given these five challenges to solve and make teams and create them using one of those data sets and the challenge. Those are the only things and also have fun. And from there they were two teams chosen from each location and they continued on and from there it was about, this is actually some of the team we'll talk about in a minute, and they had about eight to nine weeks to continue building on their idea and then pitch it to the Secretary of State and the governor at May, and we had three challenges or three winners that came out of it. And the great thing is this is not just, you know, throw all the code you can for a presentation for, you know, 24 hours, three hours or whichever, but then also actually solving problems for our businesses locally. So I thought we would talk about it and there are here the dates. You guys are interested. Check out gocodecorretto.gov and this is a business Colorado, which is the second place in this past one out of Durango. And that's it. All right. So yeah, this is a talk about using the swagger tool chain. So I'm Tim. I work at Living Social on a team that develops a lot of services. And Tony, my co-presenter who is in here, and I have been actually contributing to a gem called Swagger Yard. And what this mainly is, is something to really help you test and document and describe your RESTful APIs. So this talk is about giving you a conceptual overview of the tools to show off some of the cool things you can really do with this. So yeah, first question is why even, you know, why on earth would you document a RESTful API, right? It's just RESTful, right? Well, really RESTful doesn't say much, right? So you still haven't said what HTTP statuses you'll be using for success and error messages. Will you have 200s or 204 responses for posts and puts? What kind of 400 code range messages do you support? Where does, you know, do you have any load that goes into the body saying, explaining the errors? All these kind of things. Where does authorization and authentication go? Yeah, anyway, all of that, versioning most of all, where will that go? So all of that is not really anywhere when you're having a RESTful API. Also, we wanted to have a way for our clients to play around with our APIs. And from a client perspective, that's really cool that they can pretty much test it out before it's even there. And then Swagger actually comes with a tool chain that provides you with HTML, CSS, and JavaScript to consume your API descriptions and then play around with it. It has a really, really spiffy UI that not only documents, but even, again, lets you make those calls. So Swagger can serve as a general cross-platform IDL and can actually be consumed by various languages, like there's Binding for Scala, Java, HTML5, and you can generate client gems in a build step, if you like. Or, I think Objective-C, Python, PHP, all of those are there. But don't panic, you don't really have to use the code generation. If you don't like it, a lot of people really feel bad about that. So coming to that, there's basically three parts to Swagger. Then first one is Swagger Yard. So what you see is you're actually documenting your controller actions by saying, hey, this is what it does, some general notes. And then generally, how you get there with get request. And then what the path goes and what the parameters are. And then you explain the parameters. And yeah, then it's basically just a gem that you're mounting inside your Rails application as an engine. And yeah, you go ahead and define things like a parameter, a response type, an error message, just fully describing what this stuff does. And it generates a JSON file specifying the API as an output, a sample of which will you be seeing now. And then after that, you can actually use, you can read this, and this is basically a specification of your API in JSON for all the various things like the path for your API endpoint for your operations. And this is the way that Swagger Yard spits it out. And that's actually the standard specification for Swagger, which is an open source project. And then again, you'll actually get to a UI Explorer, which is really the cool part here. You get to play around with it. You see all the documentation. You can actually talk to the service there. Well, demo time, this is actually a recycled demonstration. So what I'm just gonna be doing actually is just show you, oops. How this thing works out. Let me actually try and reload here. There we go. So as you can see, I have a local service that's running here. I can show and hide all the various operations that I have just documented. And let's say I just want the location for a user that's there. So here you can actually describe what is the model, what is the stuff that's being returned with all the various fields on your model. And then here are the bold stuff is what's required. And this stuff is kind of optional. So you're doing a client name is required and a person ID is required. You can go ahead and make a call. And there you go. You already have your results. And just to show you this is not just fakes. Just take anything in there. You'll actually get a 404 response. So this is some cool stuff. I think it's really useful for us internally. Final thoughts on this. We actually use this a lot to get feedback while we're designing. So we can actually just document our APIs, our control reactions without even implementing them and give this to our clients so that they can play around with it. This gives us really quick feedback and usability even before we're issuing this stuff. And then, yeah, we can adapt quickly and iterate quickly. You're designing first, right? So the next thing is we'd really like you to go play and contribute to this. So it's all open source. We actually unfortunately at Living Social went to forking this because we had a hard time getting pull requests served. But if you're going to our fork of that under Tony Patali's GitHub handle, then we promise we'll be better at pull requests. And, yeah, next steps for us is actually we want to have this in our Tech Hops website to be in one central place where we have this Swagger UI and then just have all our services documented this way. So we have one central place of going to do this. And another thing we're actually really wanting to do is, like, on-the-fly client creations. So not just have a build step, but some... have a Ruby gem that actually consumes the API and then automatically gives you, based on that API, an in-process automatic code generation that gives you a DSL to talk to your services. So that's it. And, yeah, I hope more people are going to be using this. Thanks. When we talk about dashboards real quickly, my name is John. I'm a Ruby developer at LifeChurch.tv. There's five of us here from Oklahoma City. So thanks for having us. Yeah, thank you for the whistle. We just real quickly... We're part of a really big church in Oklahoma City. We are actually on a really unique team internally that builds web applications for us as a church. And then we turn that around, create SaaS products for other churches for free. And so we get to work on a couple of really cool projects, one of which is the Bible app. Have you ever heard of it? It was about 20 minutes ago. It was about 154 million installs. So that's kind of a thing. So why dashboards? You're typically ever going to create a dashboard for one of two people, either this guy, who you're going to probably be doing acquisition numbers, retention numbers, probably things with dollar signs, or this guy, who we're going to talk about today, which is the majority of this room. So quickly talking about what we use for our dashboard at work is called dashing. It's a project out of Shopify that we really, really, really like. Super easy to install. There's a gem and you install it. Dashing, new, whatever you want. Bundle it. Dashing start is what you're going to be running. And really quickly out of the gate, you can start playing around with. They've got a bunch of really nice default CSS. You can drag and drop layouts and do all kinds of fun stuff. I don't like the Windows 8 colors. So we kind of did our own thing, which I'll show you in a second. But basically how this works is you're going to collect your data. So coming from the bottom up, collecting your data from a scheduler task, from whatever service that you want, whether it's external or even internal databases, pass it up into JavaScript or CoffeeScript, and then the HTML is really, really basic. You're basically just telling it where to display and what data bindings you have. So let me show you ours real quick. Unfortunately, it's scaled for TV and I got to chop it off here, but you can kind of get a good idea of it. So at the far left, we've got our code climate numbers currently, which I feel okay showing you because they're not that bad. There's no twos, so I'm good. And we have last week's numbers below that. Our products basically go. We've got four products that are going left to right with our kind of color coded there. Right next to that is kind of server statistic stuff. All that's pulling from New Relic, including sidekick numbers. When I loaded it, Uptime hadn't run yet from Pingdom. We've also got failed jobs. You can see that 24 up there. Matt, can you get on that real quick? Thanks, buddy. Next to that is OpenPRs from GitHub and then Trello is right next to that. We've also got ticket support up top and what's currently playing on our in-office RDO. So real quickly overview, we've got data coming in from all of these different services, and as soon as you get one set up, you can kind of get the handle of it. It's really easy to integrate whatever else you want into that dashboard. So before I wrap up, let me show you some really basic stuff. This is from Code Climate. I think I pulled out the API keys. I did. So basically just using HTTP Party, going out, grabbing their API, consuming it, basically creating this little data hash down here, and then that send event is what dashing is looking for. That's going to pass that off to the JavaScript, which is listening, and then we'll render that data. And then you've got a timer on the scheduler. I don't need to, probably even three minutes is a little aggressive. Our code doesn't change that much. A little bit more complicated would be RDO. That API sucks, but thankfully, after a couple of days, we figured it out. Time was spent. So calling in basically what songs playing and sending that out, and then finally New Relic, which is even crazier. Testing, clean code? No. We'll just go. Pulling all the kind of metrics out of RPM and all that kind of stuff out, and being able to see that is actually really helpful. Whenever you see zero milliseconds, it usually means something's bad. You can trigger stuff with the JavaScript in terms of flashing things red, doing whatever you need. We've got that on a big TV in our office. It's really handy for us in the mornings. So if you want to play around with it, dashing.io, if you've got questions, hit me up on the social services and such at Jay McCarty. Thank you so much.