The Altman Building,
135 West 18th Street, NYC
Programming history is filled with bugs that turned out to be features and limitations that pushed developers to make even more interesting products. We’ll journey through code that was so ‘bad’ it was actually good. Along the way we'll look at the important role failure plays in learning. Then we’ll tame our inner perfectionists and tackle an approach to writing code that will help us fail spectacularly on our way to coding success.
Memory usage can be difficult to analyze. In this presentation we will cover different techniques for analyzing memory usage of a Ruby process including in-process analysis tools as well as system level tools. After doing memory analysis, we'll look at some ways to reduce overall memory used by the system. Attendees will leave with practical tips and tricks for memory analysis in their Ruby systems, as well as a better understanding of Ruby internals.
Whether you call it microservices or SOA, service autonomy is the quality of the architecture that dictates whether you end up with the services implementation of your dreams, or a tangled mess. Event Sourcing is the path of least resistance to service architecture, and the only way to realize the service autonomy that keeps your efforts from going off the rails. With examples of service components produced entirely in Ruby, this presentation describes the patterns and anti patterns of service architecture, and demonstrates the basics of message and event-oriented design, development, and testing.
Anyone that's developed with open source has probably been burned by a dependency issue of some sort. The time spent (minutes? hours? years?) debugging dependency-related code adds up- but lockfiles drastically reduce the headache! I'd like to discuss the ins and outs of dependency management in Ruby, a little history, and how lockfiles give us our valuable development time back.
We hear talk about running 1,000s of RPS on Rails, but what about running 1,000s of jobs per second? Jobs often go unnoticed and have much fewer patterns than controllers or models in Rails. def; perform; end, done!
In this talk, you'll learn the patterns we enforce at Shopify for writing jobs at scale. How do you deal with jobs that run for days or weeks when you fail over data-centers? How can you automatically partition workloads over multiple workers? How can you help developers write idempotent jobs? By giving jobs a bit more structure, we can greatly improve their utility.
With ongoing attacks on consumer sites and the looming GDPR deadline approaching, protecting user personal information is more important than ever. In this talk, you will learn about:
By the end of the talk you’ll be inspired to encrypt your users’ data as well!
Currently, our industry has a surplus of bright junior developers, but a lack of open junior positions. Building a developer apprenticeship in your organization is a great way to provide a haven for these talented devs, while simultaneously making your team more productive and easing the pain of hiring.
In this talk, you'll learn from the mistakes I've made and wins I've had in creating an apprenticeship. From pitching the idea to growing your apprentices, you'll gain a step-by-step guide to successfully building your own apprenticeship program.
As engineers we place a lot of emphasis in the things that we build. However lots of the software we write is destined for deletion. What does this do to our definition of 'doing great work'?
Is "great work" inherent to the code you write? Is it your customer's results? Is it anything to do with the output in the first place?
Come and examine the role of teams, personal relationships and your own attitude in your day to day work, as well as in the broader cycle of a whole career and our industry.
In the recent years, microservices have been an investment among many engineering teams as they scale. They are often the default of many new companies. But how has that gone wrong?
This talk will dive into how one company refined their thinking on their service-based architecture for the better. It will cover reasoning about services; drawing boundaries in large Rails applications; the differences between services and applications; and when to finally extract a new application.
These days new Ruby releases are regarded with less and less fanfare. We rejoiced at all the new features and support of Ruby 1.9 and 2.0! Since then, we've become a bit jaded: "Refinements? Yeah, they're OK." "Immutable String pragma? Yawn!" "
yield_self? Don't we already have
In fact, Ruby has delivered in myriad ways over the last several releases. From more support for functional-style programming to vast speed improvements, the Ruby core team is firing on all cylinders. Let's talk about what's been done, what's on the horizon, and get excited about programming Ruby again!
Most web applications have RESTful APIs for either internal or external use or mobile apps and that comes with many approaches to design and standardize for a team. If you’re already using JSON responses, following the JSON API spec is a natural progression to provide consistent responses. In this talk, I will give an introduction to the spec, it’s main feature benefits, how it can be implemented in a Rails app and the lessons learned.
PaaS, CaaS, or FaaS? Each year brings more options for where to run a piece of code. As application developers we follow guidelines like The Twelve-Factor App to make sure our apps can run anywhere. But what about our functions? How do we make sure our functions can run anywhere?
In this talk, I will introduce a way of isolating business logic so that you can easily move it from a browser to a server to a serverless function and back.
We all operate software, and we all know that it can fail. There's nothing quite like that adrenaline inducing, heart rate raising, spine tingling moment when you know something is broken, and you are the one to fix it. But the question is, once you've fixed it, what happens afterwards? How do you make this never happen again?
In this talk, you'll learn about postmortem analysis. A tool you can apply to make your production software more resilient to failure. You'll learn how to understand human vs machine cause, and how to operate your software a little better. This talk is technical, but should be accessible to Ruby developers of all skill level.
WeWork invites all GORUCO attendees for a night of pre party, fun, music, food & networking. You must RSVP to attend.
Doors open, get your conference badge and some New York breakfast
501 10th Avenue, 7th Floor, New York, NY 10018 (Yellow DHL Building. Entrance on 38th street.)
A huge thanks to our amazing sponsors
We aim to remove obstacles for attendees from under-represented minorities and strive for equal access for everyone. Apply for a scholarship ticket!
In addition, we thank our scholarship sponsors who help make it possible:
Send us an email email@example.com
Follow us on Twitter