STABLE: Making Software Design Work in Real Code
Static Analysis Tricks for Ruby
Ruby and Postel’s Law
Quit Ruining Perfectly Good Ruby Developers
Money Makes Your App Go Round
Surviving the Framework Hype Cycle
The Missing Step in Rails Controllers
Enter by Bootcamp
Conveying Intent: Why Cucumber is still relevant
Players Gonna Play: The importance of recreational programming
At the end of the last century, Robert Martin created an iconic acronym out of five different software design principles: SOLID. Together, these five principles describe a beautiful world of flexible and readable code. Thanks to SOLID, we know what good code looks like. Twenty years and millions of mudball codebases later, we're clearly still missing something. It turns out that it's not enough to just know what good code looks like. We also need to know how to improve existing code -- make it more SOLID, if you will -- without throwing it away. Rewrites are fun, but are rarely a viable option in our world of schedule pressures, colleagues who are counting on us, and quarterly KPIs. In this talk, I introduce STABLE, a new set of techniques that bridge that gap between SOLID and real code. STABLE gives you a roadmap towards SOLID code and lets you do good software design right now, in the real world, starting with what you have. No rewrites or "refactoring sprints" required.
Sarah Mei is the Chief Consultant of DevMynd Software & has been writing software since before the internet had cats. She teaches object-oriented design, is an expert pair programmer, and loves speaking and writing about the intersection of code, architecture, and teams. Sarah is also a director of Ruby Central, a founder of RailsBridge, and a Technology Advisor for Vote.org.
Static analysis (determining information about a program without actually running it) may seem like a strange fit for a dynamic language, but for many use cases static analysis can work just fine for Ruby. For example, a security tool like Brakeman does not need to accurately understand every application it scans - it only needs to do a reasonable job of finding vulnerabilities. Building static analysis tools for a specific goal is much easier than you may think, even for dynamic languages. In this talk, we’ll cover how static analysis works in general and then go through some of the little “tricks” Brakeman uses to better understand the code it scans.
Justin has been writing code in Ruby for ten years now! He is the primary developer of Brakeman, an open source static analysis security tool for Rails, and also works on Brakeman Pro. He has been an application security engineer at SurveyMonkey, Twitter, and AT&T Interactive, and somehow got a PhD in computer science from UCLA.
This talk is about the twin open source project goals of, on the one hand, increasing participation and contribution to an open source project, and on the other hand including everyone while eliminating discrimination and harassment (whether deliberate or accidental). I'll talk about different approaches to reducing discrimination, including better documentation, better development tooling, explicit onboarding process, and codes of conduct. I'll also cover concrete steps that anyone can take to help increase inclusion and participation in the teams, communities, and open source projects that they are involved in.
André thinks Ruby is pretty neat. He leads the Bundler team, co-authored the third edition of The Ruby Way, and founded Ruby Together, the Ruby trade association. At his day job, he provides expert development, architecture, and teaching through Cloud City Development in San Francisco.
It's great that we're empathetic to each other in person, but can we express that empathy in our code too? We'll take a look at Postel's Law, learn to be a little kinder to the people who consume our code, and obsess about one method for way too long.
Joe Mastey consults as a software engineer for this and that. Recently he’s been focusing on helping companies build fantastic internal education programs. As an avid extreme weather enthusiast, Chicago has been quite kind to him, despite a distinct lack of climbable rocks.
Remember that last developer you were SO excited about they came on, and now you think they’re an idiot? It could be your fault, not theirs. Your poor communication, lack of feedback, and unwillingness to fully step into your role as Team lead is sending them a very clear signal: You’d rather be coding than managing. In this talk, I talk about WHY the maker to manager transition is hard, and 5 things you can do to become the leader your team needs, instead of ruining perfectly good ruby developers.
Marcus Blankenship works with technical leads and managers to build high-performing teams who trust one another and deliver great work. His upcoming book, Grow Happy Developers, is due out this year. He writes, speaks and has trainings & workshops at MarcusBlankenship.com.
Your customers have money, and you’d like them to give it to you. Payment gateways, such as Stripe, Braintree, and Paypal, make it easy to start charging credit cards and get the money flowing. But charging cards is only the beginning. You need to worry that your app responds gracefully to service failures, since charging a customer for a failed transaction is bad. You need to guard against fraud and security breaches. You need administrative tools that are flexible but secure. You want to test against external services. And you’ll run up against the law. Learn from some of my mistakes and build a robust financial application.
Baskin-Robbins wishes it had as many flavors as there are JS frameworks, build tools, and cool new "low-level" languages. You just want to solve a problem, not have a 500-framework bake-off! And how will you know whether you picked the right one? Don't flip that table, because we'll use the "hype cycle" and the history of Ruby and Rails as a guide to help you understand which front-end and back-end technologies are a fit for your needs now and in the future.
The Rails controller is a precarious place. It acts as the translator between the backend and the frontend, and it is the first place where code seems to gather in complexity. While it has become best practice to use a serializer to transform data from the backend to a format that is consumable by the frontend, we still don't have a way to do the opposite - to translate data from the frontend into a format consumable by the backend. In this talk I argue that much of our controller complexity comes from processing forms, and I propose a solution to help reduce this complexity.
As an entrepreneur and software engineer, Ryan is passionate about creating products people love. In 2012 he founded adultbunkbeds.com, an eCommerce company that manufactures bunk beds and loft beds for adults. In 2013 he discovered his passion for programming through the coding bootcamp The Starter League in Chicago. Ryan now owns a software development firm in Chicago called LaunchPad Lab where he spends the majority of his time building software products for startups and established companies in and around Chicago.
Dozens of coding bootcamps have sprouted up over the last several years to take advantage of the fact that software and web development has a tremendous need for developers. I'm one of many people who decided to break into the field via this path. My bootcamp, Dev Bootcamp, takes people from all backgrounds, mostly non-CompSci or STEM, and turns them into junior fullstack Ruby on Rails developers in 18 weeks. This talk will dive into why people choose the bootcamp route, what kinds of things bootcamp grads come out knowing, and how they're taught, at what speed, and to what depth. The field is being disrupted by these changes--come and hear from someone who's gone through it first-hand.
In a world of in-demand minds and ever changing job positions, your project better be ready to get developers up to speed quickly. How do we do this? We show them the manual of course. Wait... you guys have a manual for your project, right? You probably already do. It's called your test suite. In particular, your Cucumber features. Cucumber allows us to write how a feature is intended to work and then assert that it does. It is a great way to exercise the entire stack but an even better way to educate on how your application behaves. This talk will go through why cucumber is still relevant in a sea of fast running tests, why every chosen word in your feature is important, and ways to get the most out of your integration suite.
Matt is a seasoned veteran of the Ruby world, having spent many years helping build up the Ruby community in Chicago and putting in time at both Obtiva and Groupon. He’s a lover of the simple things in life, and that love translates to an ability to see the simple solutions in complex development problems. In addition to his development chops, he’s a father, husband, son, friend, software developer and unemotional robot (or at least that’s what he’s heard).
Research has shown that "play" is a crucial part of how people learn, children and adults alike. We encounter new things, discover new ways of putting things together, and find new ways to use old things. Is this true in software development as well? Let's talk about it! We'll see some ways that play in programming encourages new ways of thinking and problem solving, and we'll look at how mazes (and algorithms in general) can be a rich playground for this kind of experimentation.
Jamis came to computer programming in high school, and learned it primarily through play and experimentation. (Maze algorithms in particular have been his passion for years–he even wrote a book about them!) When he’s not coding, he’s writing, playing guitar, learning Kyuki-Do, playing Kerbal Space Program, and hanging out with his family.