Lightning Talks (Day 1)

Talks

Anna Fowles-Winkler

@annawinkler

Starr Horne

@starrhorne

3 more speakers

See all speakers

#ruby

#databases

#api-documentation

#community-engagement

#hackathons

Lightning Talks (Day 1)

by Anna Fowles-Winkler, Starr Horne, Jessica Goulding, Tim Schmelmer, and Jon McCartie

The video titled "Rocky Mountain Ruby 2014: Lightning Talks Day 1" showcases a series of presentations focusing on various initiatives and technical topics related to Ruby and programming. The event features five speakers who deliver their insights through engaging lightning talks aimed at educating the audience on coding practices, community engagement, and technological tools.

Key Points Discussed:

- Teen Hackathons by Starr Horne:

- Introduction to "Program Lafayette," aimed at getting teens interested in computing through programming workshops.

- The success of recent hackathons includes a cipher scavenger hunt and a games hackathon where participants developed games.

- Emphasis on community support and inclusivity, as events are free and accessible to teens without computers.

- Highlighting a case where participants used Spanish in their programming, showcasing diversity in linguistic capabilities.

- Speed Up Your Database by Starr Horne:

- Discussion on optimizing database queries for performance.

- Importance of using EXPLAIN in SQL queries to understand query performance and improve efficiency.

- Recommendations for hardware optimizations, such as using multiple disks and increasing RAM availability.

- Brief advice on partitioning large tables and using replicas for data handling.

- Go Code Colorado by Jessica Goulding:

- Acknowledgment of the Go Code Colorado hackathon initiative that tackles local business problems through data analysis.

- Overview of how teams worked on challenges sourced from local businesses, utilizing Colorado’s datasets for practical applications.

- Documenting and Exploring Your APIs by Tim Schmelmer:

- Presentation of Swagger as a toolchain for testing and documenting RESTful APIs.

- Clarification on API documentation needs and user interaction via Swagger’s UI tools.

- Importance of client feedback during API development, enhancing usability before features are live.

- Dashboard Dashing by Jon McCartie:

- Introduction to the Dashing project from Shopify for creating interactive dashboards.

- Use case examples include tracking performance metrics and integrating various data services for comprehensive monitoring.

In conclusion, the video serves as a valuable resource for both seasoned developers and individuals interested in community tech initiatives, offering insights into improving programming practices and engagement through various talks. The presenters share practical advice, real-world examples, and innovative tools aimed at enhancing developer productivity and community participation in tech activities.

00:00:00 I'm here because I wanted 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 that we call "Program Lafayette." I just wanted to talk to you about that today because we've had a lot of great support from this community.

00:00:34 We've also found that using Ruby and Python has 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 that spark of interest in computing. We're not trying to replace something like Da Vinci or G-school; it's really just to get to a community that 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.

00:01:20 The teens come with their friends, or they make friends that night; we have food, and we also get a little physical with them too. I've got some pictures to show you. The two hackathons that we've run this year—the first one was a cipher scavenger hunt. The teens had to decode a couple of different texts and then do a scavenger hunt in the library along the way. More recently, we ran a games hackathon where the kids developed a couple of different games, like a guessing game and a dice-rolling game.

00:02:00 For the future, I personally would like to do a language analysis hackathon; sentiment analysis would be perfect there, a basic sentiment analysis. We usually just use the Codecademy 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 to ensure they don't lose their work.

00:02:39 The teens will come and form teams that night, and we find that that works really well; usually they're paired or working in groups of three. We'll take breaks throughout the night and play some really random games. There's this game called Evolution where you start as a simple creature and migrate to higher levels of existence. Another game we play is called Ninja, which involves 'ninja chopping.' Food is always a big part of our hackathons, and the library has been great to sponsor that; we always have pizza and chips and other snacks, which the kids really like.

00:03:19 We've been fortunate to get some nice swag from donors, and the kids always love that. They appreciate the t-shirts and stickers, and it's amazing how excited they get about those. I just want to acknowledge the local sponsors and the people who have helped us make this event possible. One final note before I leave: we had two teen girls who were programming in Ruby. When they were doing the guessing game, they realized they didn't have to write their questions and prompts in English; their first language was Spanish. One of the coolest things we saw was their excitement at having their computer program write silly things in Spanish. That was probably one of the highlights of our recent hackathon.

00:04:51 My name is Starr Horne. If you haven't done this yet and if you're in charge of any servers, go and upgrade Bash. Don't listen to my talk; there's a huge vulnerability about it, 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. I'm with Honeybadger; we have a lot of data coming in, so we think a lot about the database. We run into issues that people dealt with 10 or 15 years ago. I'm going to go over a few of these items with you.

00:06:06 First, make sure that your queries are fast. To do that, you need to know how to use EXPLAIN. I'm sure you know this: you put EXPLAIN in front of a query in Postgres, and it gives you an explanation of the query. The good news is that you only need to know one thing about EXPLAIN: the rows returned. This means how many rows a database will have to look through to answer your question. The number one rule is: more rows = more problems. I've got a little homework for you; go and run EXPLAIN on count pagination queries and sorting queries for larger and smaller datasets. You'll find that these operations don't work well in large datasets.

00:07:03 Nobody wants to do that; this query optimization stuff is hard work! Can't I just buy my way out of this hole? Yes, you can. If you're using a VPS and your database is slower than you'd like, move it to a real computer, and that will probably solve your problem. Use lots of hard disks. A normal database server for us puts the operating system, logs, and database on separate disks. The goal here is to optimize for disk I/O. Get a lot of RAM and configure your database to use that RAM.

00:08:50 There's a utility called PG Tune, which inspects your computer and writes out a sensible configuration file to make the best use of that RAM. Increasing your read-ahead is another option; Linux has a cache that is set very low, but you can get significant performance improvements by increasing its size. Increase your vacuuming rate to ensure that your locks manage their locks. Use replicas for long and slow queries. An identical second database can handle expensive reporting queries. Partition large tables into smaller tables to help with data management and cleanup.

00:10:31 Finally, if you have any questions, don’t hesitate to approach me. I’d be happy to discuss databases further. As you probably noticed, there are a lot of links in these slides. I'll be tweeting out a link to my slide deck where you can find all these resources.

00:11:48 Hi, 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 quick show of hands. Did anyone go to Go Code Colorado this past year? Anyone? One, two, three? All right, I'll take it! Go Code Colorado is a hackathon initiative put on by the Secretary of State and the Governor's office. We just completed the first one last year, and year two has just been announced.

00:12:29 What I like about it is that it's an initiative using data from the Colorado Information Marketplace, based on Socrata's platform, which reaches out to businesses and asks them about their problems. Last fall, we gathered around 100 issues from businesses, narrowed it down to 25, and then five challenges to solve. The hackathon took place at five locations throughout Colorado, where these challenges were solved using specified datasets.

00:13:34 The hackathon was not just a sprint to throw all the code you can for a presentation but aimed to solve actual business problems locally. So I thought, let's discuss that. Here are the dates; if you're interested, check out gocodecolorado.gov. The site serves as a great resource for this initiative.

00:14:35 I want to move on to a talk about using the Swagger toolchain. I'm Tim and I work at Living Social on a team that develops many services. Our presenter, Tony, and I have been contributing to a gem called Swagger Yard. What this mainly does is help you test, document, and describe your RESTful APIs.

00:15:25 So first, why would you even document a RESTful API? While REST doesn't save much, on its own, you may need to clarify HTTP statuses you will use for success and error messages. You might use 200 or 204 responses for posts, and what kind of 400-range messages do you support? Where does your load go in the body to explain the errors? All these factors need consideration, along with authentication, authorization, and versioning. We also wanted our clients to have ways to play around with our APIs. Swagger comes with a toolchain providing HTML, CSS, and JavaScript to consume your API descriptions, allowing clients to test it even before it’s fully developed.

00:16:35 Swagger offers a user-friendly UI that documents APIs and allows interaction with them. This framework serves as a cross-platform IDL and can be consumed by various programming languages such as Scala, Java, HTML5, Python, and PHP. Notably, you don't have to use the code generation if you prefer, so no stress if it's not your style.

00:17:53 The three main components are Swagger Yard, which allows you to document your controller actions. With it, you'll specify what the action does, where it's accessible via GET requests and what parameters it takes, explaining their function. This generates a JSON file representing your API specification. This is an output that follows the standard specification for Swagger, which is part of an open-source project. The UI Explorer allows users to explore the API, giving them a hands-on experience.

00:19:01 Now for a demo, you can see I have a local service running here. I can show and hide different operations documented. Say I want the location for a specific user, the model details what is being returned along with required fields. Users can relay their parameters and execute calls directly to the service.

00:20:04 We often use this feature internally to gather client feedback while designing. It allows us to document our actions without needing to implement them fully first. This helps us gain quick feedback and usability insights before the features are live, helping us iterate quickly. Lastly, we invite everyone to contribute to this open-source project and explore the Ruby gem that eases the process.

00:21:43 Lastly, let me introduce Jon, who will talk about dashboards.

00:21:59 Hello, my name is Jon McCartie. I'm a Ruby developer at LifeChurch.tv. We have a small team from Oklahoma City here, and we appreciate having the opportunity to speak today. We work on a bunch of shared projects, one being the Bible app, which we recently hit 154 million installs, so it is quite significant.

00:22:49 We are going to discuss dashboards, which are created either for executive stakeholders tracking acquisition and retention numbers or the majority of the technical teams here. We utilize a project called Dashing, which is from Shopify; it's simple to install. Creating a dashboard is as easy as running a few commands and playing around with layouts. We collect data from various services, displaying it via simple HTML, JavaScript, or CoffeeScript.

00:24:02 Here's a quick look at our dashboard setup in presenting data like our Code Climate numbers. It offers visibility into various aspects like server stats, New Relic performance metrics, open pull requests in GitHub, and ticket support status.

00:25:50 It's pretty flexible—once you set it up, you find it easy to integrate any other services into the dashboard. As we wrap up, I encourage everyone to play around with Dashing.io. If you have questions, feel free to reach out to me.

Rocky Mountain Ruby 2014