Playing is simple, even a child can do it, but designing something simple is hard. How can we combine prototyping with production software to get our ideas in front of real people? How can we evolve our software over time? How do we measure if something is fun?
I will talk about how Ruby’s flexibility and a strong testing ethos can bring some sanity to this uncertain world. And when I say testing, I’m not just talking about RSpec, Cucumber or Capybara, I’ll share stories from Mightyverse about how we test whether our software actually “works” for the people who use it — sharing failures, I mean, learning, as well as success.
Rails models are simple, but your domain’s models might not be as simple as Rails would like them to be.
Modeling large, complex domains "the Rails way” can cause some serious pain. Ruby and Rails are supposed to make developers happy. Let's not allow “the Rails way” and complex domains to take the “happy” out of ruby development.
Join me as I’ll walk through a set of easy to implement Domain Driven Design (DDD) pointers. The goal is to make sure your model’s business logic stay under control no matter how complex your domain is or gets. Your application will be able to sustain steady growth and dramatically reduce business rule related defects, all the while, staying easy to grok.
I'll walk you through:
How communicating the domain properly will make an imprint on your codebase and product. How creating boundaries around clusters of models will make your code easier to understand, manage, and interact with. How immutable objects eliminate unnecessary complexities. How data store access expresses the domain's intentions. How to represent natural business transactions between models.
It's 2015... your stakeholders have decided that PayPal is out and Stripe is in. Fortunately, you're a planner. You have all of your PayPal interactions isolated in an adapter gem and your interface is clearly defined, easy to re-implement and enforce. Rewriting your adapter isn't small, but it is surmountable and can be estimated accurately so it won't lead to surprises. You win.
Larger Rails apps are moving towards Service Oriented Architecture with adapters (typically custom gems) abstracting 3rd party services. This talk will cover defining, enforcing and test-driving the interface for your 3rd party service to provide easier flexibility in the future.
RubyMotion is a project that allows you to create native iOS apps in ruby. It is basically a compiler of Ruby into Objective-C which gives you access to all the iOS system environment.
This talk will give you a basic overview of RubyMotion/UnderOS concepts and I'm also going to livehack an application on stage to give you a sense of how it looks and feels like.
00:00:00 - Teen Hackathons by Anna Fowles-Winkler
00:04:06 - Speed Up Your Deatabase by Starr Horne
00:08:11 - Go Code Colorado by Jessica Goulding
00:10:38 - Documenting and Exploring your APIs by Tim Schmelmer
00:17:07 - Dashboard Dashing by Jon McCartie
Your Rails app is full of data that can (and should!) be turned into useful information with some simple machine learning techniques. We'll look at basic techniques that are both immediately applicable and the foundation for more advanced analysis -- starting with your Users table.
We will cover the basics of assigning users to categories, segmenting users by behavior, and simple recommendation algorithms. Come as a Rails dev, leave a data scientist.
We all want to work for a company that cares about and promotes a balanced, fun, and, in a word, "awesome" culture, but unless you have safeguards in place against bad clients, bad projects, and bad apples, your company culture only exists on paper.
What can we do as developers, team leaders, and mentors to protect ourselves and others from cultural failure? What are successful companies doing to maintain their workers' happiness? Is it ever okay to "fire" a bad client? What separates healthy internal pride and corporate propaganda?
This talk attempts to define the amorphous term while exploring the difficult task of owning your company culture and protecting it when things go wrong.
fluffmuffin, peppercorn, gilligan — those are just a few of our users' plaintext passwords.
I have 80,000 more, and it only took me 87 seconds to gather them from our customer database in a white-hat attack.
In Act I, we'll cover the history of secure password storage, examine the hack, and mitigate the threat. Act II will address the difficulties of working on libraries with complicated external dependencies (like bcrypt-ruby, of which I'm now a maintainer). In Act III, we'll celebrate the power of global collaboration via OSS.
As engineers working on a team, we all make technical decisions. What’s the best way to implement this? Where should this function live? Is this library worth using? Some decisions, though, are larger, riskier and more important than that. But generally, they’re also far less frequent.
Right now, your team might be struggling to organize the client-side parts of your application. Ember? Angular? Backbone? Flip a coin? Uh…which one has the most…retweets? These choices don’t need to be arbitrary or based on vague personal preference. Come learn a more useful and realistic approach that makes large-scale technical decisions less risky.
One of the greatest themes the Ruby community has embraced is testing. Countless words have been written, and tools coded, to make it as easy and painless as possible to write almost any kind of test imaginable. And yet despite all of the time we spend writing tests, we still end up with bugs in production, and we still curse our test suites for being too large, too slow, or too complicated.
Micro services are a wonderful thing! Until you try to test them in integration. Do you write a stub for each service? Point them to a test environment? Raise local instances for every dependency? I've tried all these approaches and they are all painful. Can't we can do better?
Yes we can! On this talk we will discuss Consumer Driven Contracts, a better way to deal with integration tests in a micro services environment.
The Standard Librarians are working to make the Ruby Standard Library more accessible to it's users, beginner through advanced. The basis for it is existing ruby-docs. The Stand Librarians have taken it further with explanations that are easier to parse, libraries grouped into categories, examples to try, links aggregated for further study and similar gems listed. This talk will demonstrate the new site, how it was made it and how RGSoC helped make that happen. Ruby's Standard Libraries have a lot of tricks up it's sleeves. Want to see some?
00:00:00 Asset Pipeline Tips and Tricks by Risa Batta
00:05:08 Alfred is Awesome by Cory Leistikow
00:08:08 The Human Connection by George Apitz
00:12:20 Methan Hydrate by Joe
00:15:50 State Machines by Marcus Morrison
00:18:58 Rails as Static Content Complie by Ara T. Howard
00:23:16 Teams Decision Making Tools by Doc Norton
00:30:15 Qtbindings - GUIs in Ruby by Ryan Melton
00:31:00 Rocky Mountain Ruby Rap by Shelby Kelly
Ruby - 2.1 brought generational GC to Ruby and instrumentation support. In this talk, I am going explain:
How it works? How it affects users and C extension authors? Visualize object allocation/deallocation in realtime, demonstrate how different GC tuning options affect your app.
Web apps are great and everything, but imagine using Ruby to fly drones and make them dance to the sounds of dubstep! Or to control disco lights and other robots! Sounds fun, right? In this talk, we will not only explore how we can write code to make this possible, but it will also be full of exciting, interactive (and possibly dangerous ;) ) demos!
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code. These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions. What is technical debt? What is not technical debt? Why should we care? What is the cost of misunderstanding? What do we do about it? Doc discusses the origins of the metaphor, what it means today, and how we properly identify and manage technical debt.