 My name is Tech and this is Mike. We have a favor to ask of all of you. We are co-founders of an open source software project for an organization called the Grateful Garment Project. When sexual assault victims seek medical attention, they are asked to surrender their clothing for DNA evidence. The Grateful Garment Project provides clothing to sexual assault service providers. We want to give them a shot at the $500 that Heroku is offering to open source software. Will you help us? We need to reach the 100 star requirement to be considered for the contest. So please go to github.com slash gratefulgarmentproject slash stockaid and star our project. Then go vote for stockaid at herokulove.com once we have added it to the list. Thank you all, have a great time and enjoy the rest of your RailsConf. 30 seconds. If you like talking to people who like Ruby and Rails, if you live in Los Angeles or you visit Los Angeles, come join us at the LA Ruby and Rails Meetup. Just go to meetup.com slash LA Ruby. We meet every second Thursday of the month, every month. There's like 2,000 people, but normally it's 40 of us. Every figure's on the website. So just go to meetup.com slash LA Ruby. Thank you. Thank you. All right. Hi everybody, my name is actually Fiona. Thank you. I'm a software engineer at Cetus Media Group, which is a digital marketing company in San Diego and this is my first RailsConf. Thank you. I wanted to tell you a little bit about my experience with going back to school for a computer science degree as a professional developer. So when I went to college for the first time, I majored in art history. And then when I graduated, I didn't want to have anything to do with art history. So I ended up teaching English as a second language for about five years. And teaching was really great, but I wanted to do something different and that was how I became interested in web development. And I enrolled in a boot camp, Learn Academy in San Diego. I'm also wearing their T-shirt today. So at Learn Academy, I learned Ruby on Rails and JavaScript that was almost two years ago. And I've been working as a Rails developer since then. The boot camp was a fantastic experience. In three months, I learned enough to be able to be a productive developer. And by the end of my first year, I was pretty confident. But I was pretty good at writing Ruby code, but I didn't understand very much about how Ruby actually works behind the scenes. I knew that at some level it was all ones and zeros, but the way that you got from ones and zeros to running Ruby code was basically magic to me. And that was why I became interested in studying computer science. So last fall, I enrolled at Oregon State University in their online post-baccalaureate computer science program, which is for students who are seeking a second bachelor's degree. So far, I've finished two courses and I'm a few weeks into my third. The first class that I took was intro to computer science, which was basically intro to programming in C++. Then I took a math class and right now I'm taking a class about assembly language. Could you please raise your hand if you know what assembly language is? All right. Raise your hand if you've ever written assembly language and raise your hand if you've ever written it professionally. Not very many people. If you don't know what assembly is, it's very low-level programming. As you can see, not a lot of people write it these days and new graduates in computer science definitely don't need to know it to find a job, but learning it will teach you a lot about how computers work. I've only been doing it for a couple weeks, but learning it is already demystifying a lot of that magic that makes Ruby work. Learning C++ was a similar experience for me. I learned a lot about things like pointers and memory management, which are really important to how Ruby works, but the beauty of Ruby is that you don't really need to worry about those things most of the time. When I finished that class, I was really glad that I had learned those things and I was also really glad that I didn't have to think about them at work every day. So if you are early in your career like me and you're a bootcamp grad or you're self-taught and you're thinking, why would anybody want to learn assembly? That's totally fine. There are so many awesome and probably more useful things that you could spend your time doing. But if you're thinking, yeah, I want to learn how that magic works, then I would encourage you to take some computer science classes. Even if you get nothing else out of it, at least you'll be able to come back to Ruby afterwards and have so much more appreciation for what it does for you. If you have any questions about computer science degrees or any thoughts or opinions that you want to share, I would love to talk to you. Please come find me later and thank you. Thank you so much. So I'm here to talk about LikeSpot, which is a Twitter art bot that I built as a side project. And here you see how it looks. The way it works, it's that you tweet at it and whatever you tweet at it, whatever word you use, it uses it as a search term and it searches in the Ixmuseum in Amsterdam's database and it goes through the whole collection and it finds a search random object for your word and it tweets it back at you and here you see it again. And you can try it right now. So if you look at your phones, I won't be offended. You simply tweet a word at it and then it responds with an image. So before I learned how to code, I had a career in art history, like a first speaker. So what really made me inspired to do this was, first of all, I just wanted to try it, try to build a bot. But also I was very inspired by something called Open Glam. I don't know if you heard about it, but it's this movement within cultural institutions such as libraries and art galleries and museums to take all their content and digitize it and make it available. So one issue with this is that you just have these vast databases or APIs. And of course that's a lot of fun, but how do you make that accessible? How do you make that fun? And how do you make sure that people want to interact with all these collections? So this project came out of some thoughts about that. Thank you very much. My name is Jackie, and this is also my first RailsConf. Thanks. I currently work at work bar as a full stack developer, but previously I was actually an atomic technician and everything changed after attending Boston RailsFridge. I decided to change careers and join Launch Academy where I made a lot of friends. Thanks guys. And then we still try to meet once a week and it's great. I just wanted to show off my final project. So I made a multiplayer checkers react on Rails application. It was a challenge to build something with complex logic rather than the usual 15 minute blog, but it also showed how you could also add some complex logic in Rails. I also wanted this game to be beginner friendly, so whenever a user just clicked on any of their pieces, the board would highlight any possible moves for that certain piece. It also ended up being very personally valuable because a lot of my launcher friends moved away from Boston and so this was a way so that we can, you know, keep up to date and just play checkers online. I had a lot of fun creating this app and I look forward to you meeting everyone over a game of checkers. Again, my name is Jackie and thank you for your time. Hi, good evening everyone. I'm Jin Yi. I work for Amazon Web Service and you got my name correct. Cool. I work on AWS SDK for Ruby. So if you are here and you use AWS, you pretty much have used the SDK before. That's great. Today I'm going to talk about a cool feature that you can get a generated Ruby SDK from your API models with API gateway service. It's totally fine that if you haven't heard about API gateway service before, it's a service that help you create, publish, maintain, secure and monitoring your API models at any scale. I'm going to give a brief demo to show what I'm talking at. It will be considered of two parts. One is gather generated SDK from API model and I'm going to play around with the generated SDK. So here you will see this is just example swagger file that called past door that they have as example on swagger.io and I'm trying to click the video so. Sorry, what do you want to do? Click the video, but if I click around to the next page, let's move to the next page. It's not set up. Whoa, really? Anyone even know what mountain this is? Okay. Mountain, do you know? Okay, so Sally. Yes, oh no. So Sally, it cannot play the demo, but it's totally fine. It's just few clicks through API gateway. So you'll be boring if you watch the demo anyways. Okay, so imagine that API gateway allows you to just click import your swagger model and there will be SDK generation tab show up after you have your API deployed to a stage that make your API usable. Have you add SDK generation? Of course you will choose Ruby and provide the name for the SDK and you will get SDK auto downloaded. After that, you will see the structure of the SDK generated. This is pretty much similar with all AWS service stream that we are shipping. Same exact structure and it also has a privilege of the features that we ship with AWS SDK as well. So Sally, I can not show you the demo for making API calls for your own service streams, but you can definitely try it out. But I can show why you'd want to check out this cool feature. So first of all, it's just ready for you to pick up once you have an API model defined. You don't need to build from scratch for like a Ruby gem that make HTTP calls to your tool service endpoint to show your wonderful service to other customers. It's just ready there. If you click through console or like few API calls, the cool part is it provide the same class experience with all AWS service gems, which means default building retry logic, which is exponentially back off. If you use AWS, the case, you might be familiar with that. Also it provide very handy method like parameter validations for API models. It also give the options for HTTP debugging and a lot of other features like that. At the same time, it also enables you all the privileges that API gateway can provide with integrations with all AWS service. You also have a wide range of authorization options. You don't need to use AWS authorizations if you don't like it. You can just do no authentication requests and you can also provide your customized authorization logic as well. We leave a module for you to fill in like that. If you are interested in a topic, there might be few links that you might like to be checked out. There's a great ring when talk last year that I gave by Alex about the more sophisticated usage for dynamic generating Ruby SDKs for integration tasks in your Rails app deployment life cycle through AWS. There's code, there's YouTube video. If you're interested in a topic, feel free to check out. And we also have log guide and dialogs available. And if you want to talk to me, feel free to grab me anytime. And we have a bird of feather session tomorrow for AWS. Feel free to drop by and talk with us. Thank you so much for your listening. Thank you. Hi, everybody, I'm Jamie. And I'm going to talk to you today about a framework that I've been working on for the past couple of years called Clearwater. It is a Ruby framework in front end framework. So you're running a Ruby code compiled into JavaScript executing inside the browser. So here we've kind of got like, you know, this is just like a drag and drop, like sort of like Trello style apps. So, you know, giving lightning talk. So I'm doing now. Learn to exit Vim, this is my primary editor, it's fine. Get coffee, getting coffee is never really done. You just always, it's always either you're getting coffee right now or you're going to get coffee in the future, right? So Clearwater itself is this bit here down on the, ooh, that unbroken, that styling. So it's this on GitHub, Clearwater rb slash Clearwater. But let's, so if we wanted to look at some code, you see we've, the drag and drop stuff, cool. I just wanted to see if that was something I could figure out because I didn't understand the drag and drop API. And the way a lot of that works is just, it's just like, we're just rendering, like, you know, we've got these objects that, you know, call these methods. And so we're rendering this card lists component. It's just a, you know, it's just a plain old, plain old object that inherits some stuff from, you know, inherits these methods, Div and H2 and UL from, you know, from the component mix in. We're pulling in some state from our application state and then I'm doing some experimental routing API. It has routing built in, so. But I'm looking to roll a different routing API. But we have some really interesting stuff here. So like all of these UI events that happen from the DOM, we're using these, you know, we're just passing in these action objects to see what, you know, to handle those. And the actions are just like a pickup card action is just an action with the attributes card. It's a very simple, very simple object here. And so when we pick up the card, like on drag start, that just says to pick up the card. We're not doing anything super fancy there. All of that happens inside of our application store. If you're familiar with Redux, if that's a thing that you've used or Elm, a lot of that nomenclature will be very similar. So our handler here just won't, when we pick up a card, we're just gonna update our state with, where the card drag object becomes this thing with our current card that we picked up, that we passed to the object. And you can see all the card dragging around that I did earlier. We have a whole, you know, in development mode, we've got this entire event list of the history of events. So we could even roll back to a previous state and even like roll back all the way. And we can see what some of this is as we drag stuff around. And it's updating all this in real time. One of the other interesting features is in development mode specifically is when we update our code in our editor, we save it and it updates live inside the browser. So it's actually compiling the code as you save it, compiling it into JavaScript, shipping that out to the browser, browser patches your live code, and then re-renders the app. So there's a lot of interesting things going on in here, this regarding UI rendering with Ruby using relatively simple objects being passed around your application, state management using sort of like functional principles pulled from Redux and Elm and a bunch of other little things to help make the developments experience easier. And so with that, I'm going to drag this to the done column because I'm finished, thank you. Okay, great. So a lot of Rails applications use Postgres as a backend data store. So I thought I'd talk about PGSTAT statements which I feel is a definitive must-have tool for your Postgres toolbox. A quick slide about myself. So I'm semi-lead solutions engineer at Citus Data. At Citus Data, we aim to make Postgres very free so that developers don't have to worry about scaling their Postgres database ever again. For that, we've built an open source extension named Citus, which basically allows you to shard Postgres across multiple Postgres servers. What we do offer that as is also a managed service, fully managed database as a service called Citus Cloud. So we run and manage that for you. Other than work, I love watching tons of Bollywood movies and also enjoy dancing. Yeah, maybe we can do a bit of that at the end of the lightning talks. So Postgres captures a bunch of statistics about your database. So you might have run functions like PG table size, total relation size to just figure out how much space your data is occupying on disk, or you might have run queries to figure out which of your indexes are not used yet, or if you have some tables which have not been vacuumed, et cetera. So all these things Postgres exposes to you using certain views and tables. But in addition to that, you can also add certain extensions which give you even more insight into what is happening in your database. So one of them is PGSTAT statements. So what PGSTAT statements does is it tracks the execution statistics of all the SQL statements executed by a server. It also normalizes and groups similar queries together so that you don't have basically each and every statement and its statistics, but also have similar statements and then average statistics for them. They are exposed to you via a view which is also called PGSTAT statements. What the view contains is basically some information about the query. So what is the query text? How many times it was executed? Which user executed that query, which was the database for which it was executed? It has a bunch of timing related information, such as what was the average time the query took? What was the total time, the minimum time, maximum time, and also standard deviation? It also has info about the number of blocks the query had to hit in shared memory or local memory, number of blocks it had to write, things like that. And lastly, it has IO related information. So how much total time did your query spend in reading or writing blocks from disk? So there's a bunch of tools in the Postgres toolbox and I'm talking about one. So you might be asking, what do I use your tool for? What does PGSTAT statements useful for? So let's talk about a few examples. So let's say you want to find out what are the top 10 queries your database is spending the most amount of time in. For that, you could run the first query which basically sorts the queries by the total amount of time the database is spent doing them. Or if you know that you are disk bottlenecked, you want to find out which of my queries are doing the most amount of disk reads. So for that, you could run a query like the second one. Or you just want to run a simple query and say, which query is my application sending the most to the database? So you can just sort it by the number of calls it makes to the database. So I want to spend some time on this query. It's a slightly more interesting and complex query than the previous one. So it basically filters out all those queries which were called less than 100 times. So you don't have one weird query which takes a long time and you spend a ton of time queuing it. It sorts the data by mean time. So basically it gives you on average the slowest queries which are running on your database right now. I would strongly recommend that you go after this lightning talk, run this query and figure out what are the slowest queries on your database. Now, along with the mean time, it also shows you the total amount of time and the number of calls so that you don't spend your time tuning a query which is executed 100 times instead of tuning a query which happens 100,000 times on your database. It also shows you the maximum and standard deviation so that you know whether this query just had one of bad occurrence or is it consistently performing badly? I just showed you an example result from one of the databases I ran. And you will see a bunch of queries. You can change the sorting and the order by columns to get better statistics based on what you want. So to summarize what PG Statements will do is it will save you time. It will track the queries which are executing on your database and it will store those statistics for you to access. What you need to do is just run queries to find the problematic queries and then spend your time selectively tuning them rather than trying to tune your entire database. Thank you. Thank you. Hey everybody, my name is Lee Richmond and I run a project called JSON API Suite. I very much liked David's talk yesterday about where he talked about replacing hand typing SQL with active record. Because I feel passionately that our modern day WS Death Star is single page app, JavaScript development and API design. I think the same way that we replaced hand typing SQL it's time to replace hand typing HTTP calls. This is an active record clone written in isomorphic JavaScript. You can run it from node or from the browser and the key difference is instead of generating SQL it generates HTTP requests. And it's able to do this by looking at our modern day best practices for our bleeding edge JavaScript applications like GraphQL that are treating the API like a database. I believe that we've already figured out the right abstraction for the database. It's active record. And so we could make this call generate a GraphQL payload. Instead we actually use something called JSON API. Now we're familiar with JSON API. Think restful GraphQL created by Yehuda cats. One of the reasons that we use JSON API is so we can go back to traditional Rails development. So you'll still end up with a normal controller. You'll have seven restful actions. We've tried to adhere to normal Rails best practices as much as possible. This would be really the brunt of the code that you would write to satisfy that active record query that you saw earlier including the pagination, sorting, sparse field sets, things like that. Now I know that this looks like a bunch of Ruby, one-liner, magical bullshit. So here's what's actually happening. It's a pattern that you already use. Imagine that you're in a controller and you're trying to satisfy that JSON API contract. You would start with a base scope and you would say, okay, well, if the filter by name parameter comes in, here's how I wanna modify the scope. If the sorting parameter comes in, here's how I wanna modify it. If the pagination parameter and so forth. And so rather than typing all that out line by line, all in your controllers everywhere, we would wanna extract that code and leave developers with only the part that they care about, which is the part that you modify the scope. That's what that resource object was. And even here, you can see, okay, this is gonna essentially be the same query for active record as long as we're gonna do a straight equals every single time. So we can eliminate even that and just have that be the default and that's how we ended up with our one-liner. Of course, you can always pass a block and manually modify that scope how you want, which means that you have complete control over the query here. And because you have complete control over the query, those examples we're using active record, but this works with any ORM or data store. We have open source contributors using this with Neo4j and MongoDB. You can make raw HTTP requests to a third party with it. You can actually do a single request and combine SQL and NoSQL very easily. Again, we're trying to stay as close to Rails best practices as possible. So our serialization layer is basically active model serializers. It's actually created by the current owner of that repo. And we also have end-to-end integration test helpers. So I've never been a TDD person. Now I am. It's actually easier to write this test that validates all of my keys and all of my values and guarantees backwards compatibility, including types than it is to spin up a browser and load local seed data. So it's completely changed the way that I develop and given a higher level of confidence to my tests. All of this is automatically documented in Swagger. It's a DSL after all, so we can introspect it and generate a schema for you. And the same way that we can read multiple entities in a single request, we can write multiple entities in a single request. So finally, after 10 years, nested forms became easy. This is going to save the employee and the positions for that employee and the departments for those positions all in a single request. And validations are just gonna be built in by default and you won't have to really add any logic to make it work just like you do on the server side. Now, if you did all of this and you followed that conceptual compression and we've lowered the amount of overhead that we have here, you can actually rethink the concept of microservices. I've actually staunchly advocated against microservices for years, but then I ended up with a Ruby client that looked like active record and just happened to generate HTTP. And it started to become easy to communicate across my services. And now that it was easy, I no longer had that overhead. I no longer had a lot of the problems that I used to have with microservices. And so this is actually the direction that my company is now heading. We have 15 different microservices. So in conclusion, if you want the latest and greatest bleeding edge, JavaScript, single page app, best practices and treating your API like a database and you want all the benefits of that type of development but you want it to still be as easy and simple and beautiful as Rails in 2005, then I hope that you look into JSON API suite. Thank you very much. This is how politicians in Spain look like. They get our money and they steal it. One way they do it is through public contracting. Get an envelope, they put some money in and give it to the politician and then they get million dollar contracts. It's terrible, it's terrible. Another big problem that we have are how loss are made and passed. Why? Because of people like this. People like this that push for loss that only benefit themselves and against 99% of the population. To try and fix this, we've created a console which is an open source platform with what we believe are the basic building blocks of a direct or participatory democracy. Which are participatory budgets. I work for the Madrid City Council and every year we do participatory budgets with 100 million euros. And how they work is that the people submit proposals and the government gives a monetary value to each of these proposals and then the people vote. Very similar to a shopping cart. I want a hospital, I want a park, I want a school and that's all your budget that you have. And then the government executes these proposals. Another great thing that we have is public contracting. To try and reduce this bribery that happens. We've changed the way that public contracts are given to companies. We had to transform our main square, the biggest one in Spain, Plata España. And what we did was we asked all the architects in the country to send us their proposals for the main square. And we had 72 viable projects and we put them all on the website. And there the population could see the projects, the pictures, the specifications, comment and vote for them. And the one that won is a beautiful project full of trees, places for kids to play, bicycles, concerts for music. Fantastic, fantastic. Another thing that is software implement is collaborative legislation. We want the people to participate in the creation of laws. And for that, we want to create a new law. We put the draft of the law on the website. And then the people can interact with that law. They can comment new paragraphs that they would like to see added or paragraphs that they would like to see removed. They can vote in favor and against these things. And these contributions are taken into account in the different drafts of the law before they reach the House of Representatives who is finally voted. Thank you. Another great part is the citizen proposals. This is inspired by Switzerland. Any citizen can propose at any time something cool. And if they get enough signatures, then we set up a whole big democratic party where the whole city can vote in favor or against this proposal. We set up different channels for voting. One is obviously through the website. Another one is through physical voting booths all around the city. And also through mail, we send you a letter home and you fill in your ballot and put it back in the mailbox. Calculate the votes and we show the results to see if we do this proposal or not. And this is a binding consultation. A referendum. Can't really say that word too loud, but that's what it is. The future. The future looking good. We have a lot of contributors. Thank you very much. We have a great core team pushing forward lots of good changes and bug fixes. Big shout out to our top contributors too. Thank you very much. And we are expanding. We are in 70 cities, in 15 countries. These are real governments that are using right now in production consult with this different section. We're very happy, but we still got a lot of work to do. So if you like these ideas, please help us. Thank you very much. Hi, I'm Chris and I'm curious, how many people don't know what this means? Can you just see? Wow, so about half. So I've been involved in the Ruby community for a while and one of the main things that I liked about it when I first discovered it was this, meniswan. So it stands for Matt's is nice and so we are nice. And it goes back to the early days of mailing lists and things like that. And when folks would come in and bring behavior that wasn't in line with how the folks wanted to deal and interact with each other, they would kind of go back to this meniswan thing. It doesn't solve all the problems. It's not magical, but it is just a good tenant. And I remember being impressed with it and want to make sure that we keep it alive in the Ruby community. So when you're interacting on pull requests and in the documentation and in the code you write and with each other while we're all here, let's think of meniswan and Matt's and be nice to each other. So in the spirit of being nice, I helped with a little event called Ruby for good. And I wanted to bring this up here because if you like helping animals, we work with the Smithsonian Institute and Research and George Mason University researchers. We work with a number of diaper banks, habitat here for humanity. A lot of these good, charity organizations that don't necessarily have technical skills that the folks in this room might have can come in and really solve some problems for them and make a big difference in them doing their jobs. So the good thing about doing this is we get to come together. It's a four day event. We get in the room together and we work on projects and we make a big difference. And we've taken people from having answering machines that they use to transcribe and write something down and put it on a thumb drive and mail it off to people which was a real life project that real scientists were actually using. And we were like, hey, there's this thing called web forms and we built it for you already and it removed their overhead and made their jobs much easier. The nice thing about this is there's open source projects for lots of different people at a lot of different skill sets. And so if you're interested in doing that, if you've never led a team and you want to come in and be able to do that and build it up and learn those skills if you want to network and get to know people, come to a conference where you get to make a difference and help out, you can do that. This year we're in Washington, DC, Georgetown University. The event is sold out but the reason I'm still up here talking to you is that we always do need help on projects. We also need projects, especially if you have something that you are passionate about or you believe in or have contacts in a non-profit or other charity. Please come and talk to me. Find somebody else that has the ruby for a good shirt and I'd love to find out more. And again, this is really for people of all levels. We absolutely need senior folks that can come in and have had the experience but we want to build up the next generation of tech leaders. We try to have every project as two leads and we work together. We have lots of issues on our GitHub, lots of different projects. We try very hard to tag and open them up so if it's easy to work on something that you can come in and pick it up. So if you have something or you're looking for open source work to do or want to contribute, I think this is a great way to get started. And in closing, we do have a scholars program similar to how we have one at RailsConf and we fund that through a supporter t-shirt sales. So if you would like a lovely t-shirt and want to help a scholar pay for their way there, go buy a shirt. Anybody interested, please come and find me. I'd love to talk. Thank you very much. All right, before I get going, given the current state of things with the internet these days, concerns over privacy, over control that people have own information, I just want to say this. Everything I'm about to say is off the record. Greetings, my name is Chris Morris. I'm the director of engineering for Mystery Science, not Theater 3000. We make awesome science videos and activities for elementary age kids. If you want to come help save the next generation's brains, come join us. Five years ago on this very spot in Portland, Oregon, I gave a lightning talk on imposter syndrome called technical intimidation. I've returned today five years in the future to talk about something completely different. This is my profile on GitHub. I'm not showing this to you to brag about the huge number of repos I've forked and never done anything with, nor is it to share my joy over being the only online service where I've been able to obtain my preferred username without having to resort to creativity, like this, or this, or in the worst case, that one, but to pay tribute to why the lucky stiff for my avatar of a cartoon fox that he drew and I might be in copyright violation of. Seven and a half years ago on the internet, my friend Glenn Vanderberg started this site, yday.org, which today has clearly been taken over by a very lonely German who's into sports betting on goats and bingo. Now five and a half years ago, not on this very spot at RubyConf, a wonderful documentary on why by Kevin Triplett was shown, but we don't even have time to talk about it. This is a lightning talk. So we'll skip to the part of the book that Y wrote about Ruby, where cartoon foxes showed up and started saying chunky bacon. So, who's into conspiracies? Fools, don't raise your hand, that's what they want you to do. If we translate chunky bacon into German and then back into English, we got our first clue, lumpy bacon. If we translate that into a Y language, Yiddish for example, and then back, we get lippy bacon. Now, I have no idea what that is, but look below it. Did I mean lipsy bacon? Hell yes, I meant lipsy bacon. With a search on that, and then an obvious connection through Ralph Lauren, we find a rare thing on the internet, a Penta Google Wacke. But not only that, a five part term Penta Google Wacke, a meta Penta Google Wacke. And we only have to scroll down on this page to see who is sponsoring this insanity. That's right, Stitch Fix. A sponsor of this very conference. And we know what this means, because Stitch Fix has no anagrams, none. I mean for crying out loud, my own name has 43, including the such obvious ones as Mr. Serosis, though that does give me another username option. How does Stitch Fix have zero? That makes it an anagram prime, a primagram, which obviously means I've started a cryptocurrency based on websites with primogram domain names. Pizza.com's the only other one I've found so far. But if you'll join me in the hall after this, you can get in on the ground floor. Now thanks to my previous presenter, we have, and know what this acronym means in our community. So it means Matt's is nice, so we are nice. Now admittedly kind of, except for me, I'm a little bit of a jerk, but it's okay, I have imposter syndrome, so I'm not really a jerk. If Matt's is the father of our community, Y is clearly the guy who crashed your kid's bar mitzvah, but brought along his DJ gear and saved your chunky bacon after you showed up with a dead iPod and left the charging cable back in Jersey. We owe Y more than a site that's been devoured by lonely, gambling addicted Germans. Seven years ago, this very day, if today we're August 19th, I created a special term in honor of Y Day. Now, like any good conspiracy, I've lied to you. I've tricked you. I told you Stitch Fix has no anagram, but clearly that's a number one up there, right, programmers? But there is a term that has no anagrams because it's pure nonsense. And like any good developer, I registered that nonsense as a domain and today I'm unveiling wixwack.org. What kind of bacon did the foxes want, chunky? What is special about chunky? It's thick, it's luxurious, it's generous. So ask yourself, what would Y do? Like anyone could even know that. You do you. Nobody wants skimpy bacon. Be generous and be chunky. Thank you very much. One exception to my mispronouncing rule, if Y shows up here, I will definitely pronounce his name correctly. So if you're out there, that's an invitation. Next up is Thummies Thomas. Yeah, I don't know why I do this every year. Oh, thank you. I didn't mean that, I meant this. But thank you regardless. And you may begin. Hey, I'm Andrew Lewis. I'm visiting from Canada. That's my first RailsConf and I'm gonna talk about a personal project I'm working on. I'm building a memex in Rails. Just to show hands, who's heard of the memex before? The historical idea. Cool. Has anybody used a memex before? Okay, that was a trick question, which you'll find out a bit later. So our story begins in 1945. It was a cool idea. This is the memex. So the idea was that you'd have a physical cabinet, you put it in front of you, you put all your library on microfilm and you'd be able to search and go through all your information. Everything would be in one place. It came with these add-on devices like a stylus for adding notes and drawings. It had this voice recorder for adding voice notes. It even had this clip-on camera that you could put on your forehead and take pictures for your memex. The tragedy of the memex is that it was never produced. I heard about this idea and I was really sad. I was sad that it was never produced. So I said, I have a lot of data. I was overwhelmed. So I said, I'm gonna sink. I have a lot of data. I was overwhelmed by the amount of data I have that I can't search through. So I said, I should just build my own memex. And that was a while ago. I said naively many years ago. So I got to work at building a lot of importers. So I have pretty much all my browsing history, my reading history. I have my digital consumptions like the photos I look at or the videos I watch. I have geographic trails from my phone generated all the time and all my messaging and social interactions. And then a lot of journaling and like qualitative data that I generate by myself. So this is all the data I have. I have a lot of data. I have stuff from 1995 onwards. So like my first journal and I've kind of backfilled it and I've put a lot of stuff and it's organized as a graph in a Postgres database. So there's a Rails API for, sorry, a Rails app for the API. And then a separate app, separate Rails app for the importers. And then I'm using EmberJS for the front end. So I'm gonna do a little live demo if you wanna do a quick prayer that would be appreciated. So this is the interface. It's oriented around queries. So the query that we have on the left, we're just doing a query for things that I've liked. So verb like. So this is just an example of what comes up. So these are all things I've liked recently. I can scope it down to something like this, provider YouTube. So this is like my full YouTube history. I can do something like this, provider GitHub. So this is now my full, so these are repositories that I've liked on GitHub. So you can get an idea of like how much data's in this. To show you the structure, I can turn on this graph view. So this is me in the middle. So everything's oriented around myself. This is like a repo that I liked. These are the tags that are on the repo. So you can traverse all the data. Like I can traverse all the data of my life through this graph structure. So I'll do another example. I'll do my listening history and I'm gonna do a traversal now. So I'm gonna do a traversal for song. And I'm gonna do where the creators are Aretha Franklin. So what I'm doing is looking for all songs where Aretha Franklin created them. And this returns every song I've listened to that Aretha Franklin created. It's pretty cool for just doing like a full search across like all my history for a search term. So I can do something like this Ruby on Rails. And this will search across everything I've ever seen or encountered that matches Ruby on Rails. Do I have a typo? I'm not sure. I will keep going. Oh, there it is. It was just slow. Did everybody get one of these? The Strope Waffles on the way in. So this is a Dutch treat. I got it on the way in and I knew I'd seen it before. So I was able to search my memex for Strope Waffle. And what comes up here is a picture, two pictures actually. So I knew I'd seen it at RubyConf before. So here's the picture it matched. I can get the context of where I was when I was looking at it. And it's a bit slow. Yeah, but I was hanging out with some friends. I was at the Duke Energy Center and this was in 2016 at RubyConf. And again, it's matching on OCR. So it's matching OCR on all the photos I have. So I can do some more queries. I know I'm coming to Pittsburgh. I've driven through Pittsburgh for a few minutes on a road trip. So I can pull that up. So what I'm doing is searching for just normal activities that I've done near Pittsburgh. So this pulls up the last trip I did a couple months ago. I was on the way to Strange Loop and we drove through Pittsburgh. I can put it on a map and it's not loading. I can put it on a map and see the places I've been in Pittsburgh. So that's pretty cool. I was with my friend Max. We were driving to Strange Loop. So I can pull up things that we did on the trip. So I can do this kind of query. So verb traveled in a car, automobile. It's a bit clumsy. And I can do occurred with my friend Max. So this is all the traveling I've done with my friend Max. You can see the route. And then I can search within that. So I can do something like verb photographed and occurred during verb traveled. So this is a query for all the photographs I've taken while traveling with my friend Max. And here they are. So it just gets an idea of the cool queries I can do. So I also tracked my food eating. So I can do something like this. Verb eight, burrito. So this is all my burrito history. And I'm gonna scope it down to where I live, or Toronto. So usually this is kind of useless data. I don't use it too much. But sometimes it's usual for associations. So I know that I was reading a book while eating a burrito. So I can scroll through my burrito history if I just trying to draw up my memory about where this happened. And I'm not seeing it. So I'll just keep on kind of going through my burrito heat map. And, okay, that's about time. Okay. All right, so I'm gonna just give a quick talk on embracing SQL light in production. But before I can begin, I just wanna give a big asterisk to everything. I kind of fucking love SQL light. So this is definitely biased, but if you ask anyone on my team, I've been kind of nonstop talking about it for quite some time. So just as early if you've ever worked with SQL light or anything, a Rails tutorial before, you've only ever worked with it in development. And then as soon as you realize you have to do a production app, you wanna switch everything over to like MySQL or Postgres, or I don't know, even NoSQL, I don't know. But the great thing about SQL light is that it's just a file and that you can actually read from it. And one of the things I do on my team with the shipping team is that what we wanna do is just figure out the cost of a box from going from point A to point B. And with all these different shipping providers, there's a ton of data to actually figure out this cost. So if you've ever been to a post office, it's like $25 and you have no idea how they actually come up with it. Luckily I do, so if you ever wanna talk about it, we can figure out strategies. The one thing if you've ever had to deal with a legacy character like USPS or DHL or UPS or any of these, their APIs are slow, brittle, and they don't totally know what JSON means, other than just a fancy wrapper on XML cause cool kids like you love it. So one thing that we've done is actually taking all this raw data and what we wanted to do was actually calculate everything locally. So our kind of first attempt that's kind of worked and brought us to a good point was let's load everything in memory at once right when our Rails app boots up and we're golden. Unfortunately, when you start working with more and more carriers and more and more data, things like boot up times and everything become really bogged down and it's just kind of a nightmare trying to deal with this. So one of the great things, even what we learned today which I was super excited about with Rails 6 support, adding more is just actually working with ActiveRecord and switching over to multiple databases. So we can kind of turn this naive approach with looking up through our hash and all these kind of weird, we have one thing called a reader which was a really crappy ORM. So one thing we wanna do is just embrace ActiveRecord fully and that's kind of what we've done. So the great thing with having Sean Griffin and everyone else on the team is that I can dig into documentation and also ping someone on Slack just to verify and check my sanity. So to give you a little example, obviously this is simplified but we basically can roll out different databases for different carriers and store all this logic. And one of the great things about working with carriers is that you work with lots and lots of business people and they love Excel. So we can actually quickly build a rake task and generate all these Excel files and data sets into kind of a rolled up SQL version. And if you've ever had a chance or have heard this mysterious tool at Shopify about dev, this is actually an open source gem that kind of makes working with any command line tools a little bit friendlier. So like everything with this conference, we've always been hearing this mystery question, does it scale? And the question is, yes, we've actually just seen it past few weeks, we've gone through different flash sales and everything else. And the great thing with working with SQLite, especially if it's read only, you can actually handle scale on threads. I definitely would never write to it but it works excellent for our chance. And if you are just curious, we are totally running on Kubernetes. So all the buzzwords are out. I'm hoping we can plug in the blockchain as well, but who knows? And if you ever wanna talk to me more about SQLite, I would love to do that or even Maple Syrup or other Canadian things like healthcare, just find me out afterwards. All right, thanks. Thank you. I'm Heidi Waterhouse. I'm the developer advocate for LaunchDarkly and I care a lot about stickers and you're gonna care too when I'm done with you. So this joke is a derivative of a show that went off the air before most of us were born called Suck It to Me and I'm not gonna go into it. So stickers, why do we even care? Are we actually eight years old because that's sort of the demographic we associate with stickers? But if you look at your laptop, you may find that you are secretly eight years old. We care because we find stickers delightful. We find them surprising or charming and for a couple other reasons that I'm going to go into but I really feel like delightful is a leading indicator of sticker popularity. We also care because we use them as in-group markers for identity. We want to see ourselves. I keep getting pictures taken of me with other people with weird colored hair because people can easily identify us as a group and that's super easy and also I've chosen to have weird colored hair so that's great but sometimes we don't get to choose who we are and yet we still want to see somebody who looks like us. So I have this giant distribution collection of stickers. If you saw my sticker bag yesterday, I need you to know that is half of my distribution collection. I don't bring the whole thing because it's super heavy because stickers are super heavy and the TSA does not love a giant wodge of stickers. It evidently looks really suspicious. So if I ever get stickers that have LGBTQ themes or underrepresented folks or in-jokes that programmers find hilarious, they fly out. Like I can't keep them around and I think that's awesome. Like every time somebody rummages through my sticker pile and says, oh my gosh, you have a brown programmer or a girl or a by-pride flag or a trans-pride flag and they're so excited because some company, somebody has thought of them as being worth a demographic point. There are other kinds of stickers that we choose because we are representing ourselves not necessarily as part of a group but we're representing our personal stack of development or our personal brand or the corporate stack that we work with or our politics. And by putting all of these things on a highly visible piece of electronica, we're saying these things are important to me and I care enough about them that I want to tell you about them without having to actually make eye contact or utter words because it's not always our thing. Also, I guess some people care about branding like maybe the people who buy the stickers for us because I priced out stickers recently. It turns out you can get holographic stickers for like 30 cents a piece. This is important knowledge that needs to be disseminated to more people but even regular stickers are actually like custom print stickers are a little more expensive than you might think. They're closer to the like 20, 25 cent range. So yeah, it's not much like until you start printing, you know, 2,000 stickers it starts to add up. So I think that companies really care about getting their brands on our laptop. This is a small selection of my sticker pile as it grows and evolves over the ages. Things swap in and out. Like I don't think I have any angular stickers right now because it's been a while since I went to that kind of conference. I now have a giant handful of Ruby stickers because you all are into the stickers and it's awesome. You won't see them in the sticker bag here because that would be Coles Newcastle. You already have Ruby stickers. So let's talk about sticker designs and design patterns and anti-patterns. First, size. Somebody told me this yesterday and I'm so excited. There's a spec for that. There is a spec for how big your hex stickers and your square stickers should be. Go look it up, sticker how. Also don't make them super big because unless I work for you I do not want to devote a sixth of my laptop to your surface. Like small stickers are beautiful. Just go with tiny. Shape. Think about how stickers are going to work with each other. I love the hex stickers and in fact brought in hex stickers at LaunchDarkly the first day I started. I like walked in, I'm like, hi, nice to meet you. You need better stickers. They have to tile. No kidding. So I love the hex stickers because they tile if they're appropriately sized. Circles are inefficient and also selfish because you can't either you have to like layer and not everybody's a layer person or you have to waste space and it's very vexing. We could have that space for stickers. So utility. If you want people to be using your stickers as a brand you should put your name on it. This was a great sticker. Isn't that adorable? Who likes that sticker? That's from InfluxDB and until I yelled at them they did not put their name on this sticker. And so people would be like, oh, this is so cute. Who's it from? I'd be like, I was the shrug moji personified. So I have 12 seconds left. Get out your phones. If you want a free t-shirt and you didn't get one at our booth you can take a picture of this right in and get a free t-shirt. I'm going to post these slides and they have a bibliography at the end which is obviously inappropriate for a lightning talk. Thank you all for your time and attention. Find me later if you want stickers. Thank you. Hello. It is my pleasure to speak with you today. However, I come with something that's quite vexing. You see I've been on a mission for a while. It's been many years now. Started here at Rails comp. Still seems to be a thing. And I feel like it's something that we really need to talk about together as a team and a family. And that is high fives. Yeah, there's a lot of opportunity here to really improve that. So I'm going to take this handful of minutes now and to really train all of you on the proper etiquette for a truly stellar high five. So if you could stand up if you would, stand up. Now the high five is done in multiple components. The first is, as Evan indicates, stretch. Really just get the fingers just really stretched out there. You know, like arms. Just really work that pectoral muscle and get there. Now, part of the challenge of a great high five is that it's a moment to really connect with the individual next to you. So step one is to find a partner. Find a partner. And with that partner, your first question is going to be, can I give you a stellar high five? Ask that now. Can I give you a stellar high five? Yes, Evan, you can. Ah-ha! All right. Oh, it's my day. I didn't say give one. Whoa. Clearly we have a listening problem. Okay, now back to paying attention. So the first step to a stellar high five is to ask, can I give you a stellar high five? Which you've done beautifully. The next step is to place the arm at an approximately 90 degree angle with your willing participant. Face the willing participant directly. And here's the hook. Focus on their elbow. Focus on their elbow. And then appropriately give them a high five. That's good. Now, here's the thing. For all of you out there that like to give an aggressive high five. Don't do that. No. For those of you who like to say, yeah, give me a high five. And then sort of kind of, ah, get scared. Don't do that. Go in their full force yet appropriately. So that's your lesson for today. So now I'd like you to find another partner and give them a stellar high five. Yes, absolutely. Okay, and by request, i.e. Evan, he'd like us all now to practice the non-dominant hand. Doesn't that just feel great? Now I invite all of you for the rest of the next day to really practice this. Make sure you get permission. However, all kidding aside, some people are not as comfortable about it. So while I fully endorse this, make sure you do get permission, visual or otherwise, and have a fantastic, fantastic rest of RailsConf. Thank you so much. Hello, we're at Blaire. Anyone? Okay, I'm Barrett Clark. And this is Brittany. And this is Alexander. This is Brittany Alexander. My good friend, Brittany Alexander. I work at the container store in Dallas, the retail store. And yes, we do use Docker, Brittany works at AdHoc. Despite the fact that Barrett could not remember my last name, we've been friends for about three years now. And one of... It's been a good three years. It has been a good three years. We met at Ruby conference like three years ago. And one of our favorite things about coming to RailsConf, coming to RubyConf is getting a chance to see some of our weird Ruby family that we don't get to see most of the year, we chat online, but it's nice to see each other face to face. And if you're like us and really enjoy that aspect of coming to RailsConf, we have another opportunity. And what about two weeks for you to do that again? And that is hashtag soon. And that's gonna be Rails Camp South. Woo, thank you. Sell it. So, Rails Camp South, what even is it? Well, as you can see by the beautiful pictures there, it's an opportunity for us, not even necessarily Ruby or Rails programmers, to go be people together out in the woods or something. We will go to DeLoniga, which is about an hour and a half north of Atlanta. And we will camp in Cabins. Or if you wanna take a tent, that's cool too. What else do I wanna say here? So if you wanted to go, we do offer the regular price is $3.75 now, early bird tickets, I'm sorry to say you've missed. But then we also offer a diversity ticket. If you feel that you are a member of an underrepresented group, then you get a $295 ticket. And like I said, it's just an opportunity to go be people together. You can take a computer if you want. And if you did take that and didn't open it, that would also be just fine. That said, it's kind of an unconference. So if you had maybe a talk that you were thinking about pitching for a conference coming up, then you were too shy to do it during a lightning talk. You could practice it on some people in the wilderness who don't have any cell phone reception. So they can't like upload immediate videos of you doing it. So that's nice. Also, we continue the Ruby tradition of too much karaoke and that we have karaoke too much. Some might say too much. Some might say not enough. But there's karaoke every night for three nights straight for several hours and it'll be a lot of fun. So just go to the website there, us-south.rails.camp. I can't read anymore because it's been a long time and I spent the night in LaGuardia last night. So Google Rails Camp South and come see us. Thank you. I have a question. I have a question. We have a question from the audience. Since you still have time, I have a question. Is food provided at this camp? Or should people bring their own food? So here's the deal with food. We have a menu that one of the people speaking in the microphone right now planned. You'll have three squares a day and the meal is friendly to hopefully your dietary needs or preferences. So you fly into Atlanta or you can drive but if you fly into Atlanta, you'll get on a bus and you can see a picture there of the group. That was Rails Camp East and we flew into New York City. The bus will stop somewhere and you can get off and get whatever beverages and snacks you want if you wanted to bring sandwiches or whatever you could do that to. Again, you do you. But yes, we will provide three meals a day. Thank you. Thank you. Hi everybody. Thanks for hanging out with us tonight. That's been pretty cool. My name is Jordan Byron. I work for C-Click Fix. They are a civically engaged tech company in New Haven, Connecticut. And I make really awesome mountain bike videos on YouTube so go check out my stuff and like and subscribe. I would love you forever. I'm actually not here to talk about mountain biking though. I'm here to talk about bundle update. It's that thing that you do when you try and upgrade Rails and fix all of your other broken gems. And it's also that thing that you should probably do more often because you know security and stuff and things get better and you want those new bugs too. So when you do run bundle update usually you get something like this. You like some GRP, I don't know what you are got an upgrade and you're like, that's awesome. I built a little tool to make that slightly easier. It's called gem dandy. And what this does is you run it against your repo and it creates a pull request. So this is all GitHub related. So if you're not in GitHub, you can just tune me out right now. So it'll create a pull request. I keep pointing like it's behind me. It'll create a pull request on your repo with any gems that can be updated. It'll link to the actual gem page itself. The version changes. And you can also get like a link to the change log so you can figure out what changed. So you can kind of maybe pinpoint if it's gonna be a problem or not. It's really easy. It's just a little executable. You just run bin gem dandy and then your GitHub repo. So if you were doing it on Rails, it'd be Rails or Rails. What it actually does under the hood it clones down your repo. It runs bundle lock update. It parses the diff from git to figure out if anything changed. The changes are committed if they're there and then it sends a pull request to your project. Now I know you're excited. So this is how you would do it except I didn't actually publish it to RubyGems because it kind of sucks. So git clone the repo. I'll have this again at the end and I'm sorry. It's just not quite ready to be on RubyGems. And there is one more thing. I did say automated. So you can actually put it run on a free Heroku Dino. Just run this little rake Heroku update and you can run it as frequently as you'd like. And then that means that you're gonna get pull requests every day, every 10 minutes, however frequently you want. And again, this is up on GitHub. It's open source. So you can go check it out. We have some tests. And since this is kind of long, I'll tweet out after this. So just search for hashtag rubycom for hashtag gemdandy and I'll have a link to it. So thanks. Thank you. My name is Mike and I work for G2 Crowd. We're a review site out of downtown Chicago. And I wanna talk today about profiling RSpec. And it's just something that came up for me recently. I was working on a project and everything was going well. And it seemed that one day I woke up and I had a problem, my specs were slow. And I can imagine I'm not the only person who's experienced this. A slow test suite is not fun. And most of the time that it happens, it's our fault. We did something wrong. We did things that weren't very efficient and we didn't really notice it at the time and these things grow and grow and grow until they become a problem. So this is something that I was dealing with and I knew a pretty good idea how I wanted to solve it. You know, if you wanna solve something like this, the first step is to measure it. So let's use a profiler. Let's measure our specs and let's see where the performance problems are. So we can make rational decisions when we're spending our time optimizing. So RSpec comes with a flag, just dash dash profile that if you run this against your suite, it's gonna go ahead and spit out some output once your specs are done running. And it's not particularly useful for the problem that I was trying to solve. It told me my 10 slow specs. I already knew what my 10 slow specs were. They're the feature specs. There's a reason that they're slow. I'm terrified of the code that they're covering. If anything breaks there, it's gonna ruin my day. So I'm willing to spend eight seconds testing my login flow or the credit card checkout flow or whatever it is that that thing's covering. Like those specs are slow for a reason and there's not much I can do to make those specs faster. So when I was digging through existing profilers that I could find, everything seemed to be answering the question of what my slow specs are. And it turned out that wasn't the answer that I was looking for. What I wanted to know was where should I be spending my time in order to get the most bang for my buck when I'm optimizing my specs. So in order to solve this problem, I created a gem. I called it R-Spectacles. It is a R-Spec formatter that uses D3 partition graphs to show you at a glance where you're spending time in your R-Spec suites. So as an example, here's a visualization of a test suite. If I zoom in, say to this purple area, these are the system specs. Each individual leaf of this tree is an individual spec. And if you kind of see here, you can see there's a small number of feature specs taking up a ton of time, but there's probably reasons that they're so slow. Here's my controller specs. They take up about half of the time of the test suite. This blue arc represents the time that they take. You know, and all these tests are a little bit longer, a little bit shorter than a feature spec, but maybe longer than these unit tests, which are sitting over here, when you have a very large number of unit tests that run very quickly. What I found when I run this profiler against my tests is that a lot of times you'll have a large number of tests that are running maybe just a little bit slower than they should, and they end up sucking up a lot of time out of your test suite. None of the profilers I've used before would be able to show me this. They would only show me my slow individual specs. And I found that this has been a really great tool for finding low hanging fruit when I'm optimizing my test suites. So at G2 Crowd, we use this, it sits alongside of our CI, and records the timing of all our builds. It actually lets us keep a history of our build, or excuse me, our test suite time over time. And then it also supports parallel tests, which is a question that people ask me a lot. So again, the gem is called our spectacles, and thank you. Oh man, so pretty. Yeah, so I am Kenny Brown. I also work at G2 Crowd. He already explained it, so I'm not gonna go into that. But what I wanted to talk to you about today is leaps of faith. So a leap of faith is basically when you're taking a jump and you don't know if you're actually gonna make it to the other side. This is a fantastic representation because I don't know if you've seen it on the internet. A lot of people said using physics, he's not gonna make it. I started my career in California. I got hired as an intern, and later after I graduated, I was hired full time. I later found out that when I was hired, they weren't sure about me. They had taken a leap of faith on me. I actually ended up working with Mike. He was not my manager at the time. And he was working on a side project, an internal project only, and I had no idea if I could do what it was, but I wanted to help him out. It was exciting and scary, but I took the leap. It was a quote I've seen online. If it excites you and scares you at the same time, that means you should probably do it. If you're familiar with the rest of that, it's inappropriate for the conference, but it's pretty funny. But the leap I'm talking about with Mike, it wasn't a very big leap. It was more like this. After a couple of years, I'd moved up in the organization and Mike had moved on and founded a startup in Chicago. I knew from then that I actually wanted to join him. It was Mike and a few other executives from the company I was working at at the time. I had dinner with Mike. I applied and quickly got a letter saying that they weren't able to hire me because of a cease and desist from my current employer. Well, that wasn't good for me, so I went home, talked to my wife and said, unless you say no, we're gonna move to Chicago so I can get a job at G2. That was a huge leap of faith, not just for me, but for my wife. She'd grown up in California. All of her family was in California. And to her, I was taking her away from that for a potential of an opportunity. That looked a lot more like this, without really much of a direction that we were gonna make it to the other side. Well, a year later, I got called in for an interview. I literally went in, had an hour before my flight to go help my mom move from Utah to Chicago. I interviewed, I got on my flight, was in Utah. While I was out there, my wife called me and told me she was pregnant. After two years of trying, she was finally pregnant. And if you have children, you know that it's amazing, but it's also scary as hell. Well, so a few days later, Mike calls me back and offers me the job. Remember, I moved my wife away from her family for the potential of this job. So of course, I got this uplift, the blue line. Somehow there's updraft right before the window, got taken in, but of course I said no. I took the green line. I was scared because I was having new baby and I didn't know what that was gonna do for me. I've got 99 problems and 86 of them are completely made up scenarios in my head that I'm stressing out about for absolutely no logical reason. Pretty well sums out how I felt. Mike called me back. He really wanted to work with me again. True story. He was basically in tears begging me. True-ish story. So I finally said yes because it's really tough to hear a grown man cry. It's been a few years since then and another opportunity came up. One year ago I was asked by our CEO to build a new product. Basically the only direction I had was build something on the Salesforce platform for our customers and that I had four months to do it. This time my wife was pregnant with our second child but I'd learned my lesson and after consulting with my wife, I said yes. So side note, you might notice that massive changes come in my life when my wife is pregnant so we're not having any more children. I didn't know which line I was gonna take. The project was ambitious. There were a lot of people who didn't think we were gonna get to done in time. I actually ended up sleeping in the office a dozen times or more during my daughter's first three months of life but to be fair sleeping on the couch I actually got more sleep than if I was at home with a crying baby but I did everything I could to make sure that even if I failed, I had done my best. Well I actually made it happen. It was released on time. It's in front of our customers. And one thing I really wanna point out is a leap of faith is not only a success if you make it to the other side. I've had plenty of experience in my life where I never make it through the blue line. I don't get that updraft. But what matters is you take the leap of faith because you are conquering your fears and doing something that scares you. Thank you.