What's new in Rails 4? How does Rails 4 fit in to the future of web development? Why are cats so important to the development of Ruby and Rails? All these questions and more will be answered if you attend this talk. Seats are limited, so act now!
All the Starcraft n00bs know exactly how to win. They take all the resources they can, and upgrade all the expensive tech and think to themselves, "soon i'll be unstoppable". Unfortunately "eventually unstoppable" is the same as dead right now. This type of premature optimization and abstraction can kill a business faster than not being able to scale. In this talk we'll take a look at how to pick the right unit composition (databases vs. NoSQL), balance your macro and micro (scale out vs. up), and choose the right race (programing language). If you've never played Starcraft, and can't tell a ultralisk from a firebat, don't worry there's still a room for you. Sorry, no Zerg allowed.
We tuck a lot of features away on github.com.
Sometimes the UI just hasn't been fleshed out. Or we have bigger plans in mind for the feature in the future. Or it just hasn't been finished yet. But we still want to give you the flexibility of using that feature today.
The same can be said about Git. If you've ever looked at the manpages, there's feature after feature and option after option in its binaries. Part of the strength of Git and GitHub is having access to those features when you need them, and getting them out of your way when you don't.
This talk covers both Git and GitHub: different tricks I've picked up after two years at GitHub, helpful advice on common gripes I've seen in support tickets and tweets, and just general nifty things that make you a faster, more capable technologist.
While Node.js is the hot new kid on the block, evented libraries like EventMachine for Ruby and Twisted for Python have existed for a long time. When does it make sense to use one over the other? What are the advantages and disadvantages to using node over ruby? In this talk, you will learn how to get the same power of concurrency enjoyed by Node.js while continuing to write in the language you know and love. Topics covered will include pubsub with redis or faye, building evented rack applications, and running evented applications alongside existing Rails apps.
I started programming Rails on Windows in 2008. The experience was not the best but I still made the best of it. Fast-forward to 2012 and because of tools like RailsInstaller, Windows users have things almost easier than Mac/Linux. This talk will focus on some of the best-practices that I've found when using Windows for Ruby on Rails development and is really geared toward helping people get started programming Rails in a Windows environment. The talk is sexy and it knows it so be prepared to laugh and have fun.
Most developers know enough about refactoring to write code that's pretty good. They create short methods, and classes with one responsibility. They're also familiar with a good handful of refactorings, and the code smells that motivate them.
This talk is about the next level of knowledge: the things advanced developers know that let them turn good code into great. Code that's easy to read and a breeze to change.
These topics will be covered solely by LIVE CODING; no slides. We'll boldly refactor right on stage, and pray the tests stay green. You might even learn some vim tricks as well as an expert user shows you his workflow.
Topics to cover include:
* The Open-Closed Principle
* The types of coupling, and their dangers
* Why composition is so damn great
* A powerful refactoring that Kent Beck refers to as "deep deep magic"
* How to destroy conditionals with a NullObject
* The beauty of the Decorator pattern
* Testing smells, including Mystery Guest and stubbing the system under test
* The stuff from the last halves of Refactoring and Clean Code that you never quite got to :) organizers')
Obviously, my credibility relies entirely on this talk being awesome, so come ready to laugh, learn, and enjoy yourself.
As applications grow, dependency management becomes painful, tests get slower, and development becomes less joyful. Breaking up the application into services can be a great solution to these problems, but not every team is ready to leap fully into a SOA. Carson is Zendesk's compromise to this problem. It's a Rails 3 engine host: an application that contains only a Gemfile full of engines and some configuration. In this talk we'll explore the benefits and drawbacks of delivering features as engines and how this approach can act as a stepping stone from big-ball-of-mud architectures to service-oriented ones.
What does really happen when we call a method? How do the different Ruby implementations actually figure out what code to execute? What plumbing is going on under the hood to get a speedy dispatch? In this talk we will have a look at the internals of the the major Ruby implementations, focusing on their dispatch. From look-up tables and call site caches, to inlining and what on earth is invokedynamic? Fear not, all will be explained!
You've probably heard of JRuby. Maybe you've even tried it. But why is JRuby a good idea? How can it help you build better applications? In this talk, we'll cover everything that makes JRuby awesome, from the JVM with its top-notch memory management, solid multithreading, and lightning-fast optimizing compiler, to JRuby itself, giving you easy access to Java libraries, robust Ruby compatibility, and trivial app deployment and distribution options. JRuby is an amazing tool for any Rubyist...come find out why.
Mocks, Stubs and other test doubles are a common and convenient scapegoat when talking about fragile test suites. But test doubles can be useful guides, highlighting design issues and in our application. By treating them as companions, we can find our way to long-term maintainable designs and effective test suites.
We'll look at specific, common complaints about test doubles and show how these are indications of design issues. Listening to these pains in our tests can be a great way to move from using our tests as verification to seeing our test suite as a design tool.
Coming out of this talk, you'll have a better appreciation for the techniques of isolation testing in effective test-driven design.
There’s nothing more frustrating for a developer than spending months creating an application and then having it fail because of performance issues. That’s why integrating application performance management into each step of the development lifecycle is critical to your application’s success. Of course, easy-to-use tools for performance management are rare, and often prohibitively expensive. Not to mention that they don’t reflect actual user behavior. In order for APM solutions to succeed in the Ruby community, they must be affordable, easy to use, require no scripting; and easily integrate into the development process – be it a PaaS system such as Heroku or some other delivery system. From idea formation to final delivery, Rubyists must know their product is working every step of the way.
Open source is hard but it gets much easier with a community backing you. I tried many approaches while developing fog, and thankfully, the resulting community is amazing. Now I'm doing my best to apply the same principles to the Heroku CLI and other open source projects. I make mistakes and often get lucky, but I have learned a lot about fostering community in the process. This session distills some of my techniques and explains how you can help build community around your favorite projects.
Technologists should not identify themselves with their tools. I’m not a Rubyist. You’re not a Windows person. Operating systems, programming languages, database engines, and application frameworks are just tools we use to get things done. Identifying ourselves with our technology choices is both a career- and business limiting mistake. This session will cover how what is ostensibly a “Rails shop” is actually far from being a Rails shop and how important that distinction is for the success of a real business. We’ve all heard the notion that Rails “doesn’t scale”. It turns out to be true. And it’s a universal truth of all technology choices. We’ll talk about how we get around the limitations of our platform of choice as well as some general strategies for opening the mind to better architectural choices by embracing technological heterogeneity.
A story of a Ruby programmer having to understand that learning Erlang is more than just syntax. Learn differences in paradigms, pitfalls and applied use cases for this incredibly powerful language.
* Concurrency (Threading, Reactor pattern vs Erlang processes)
* Stateful services
* Non-blocking calls (e.g to an http service)
* Inter-process communication
* Inter-service communication
* Event handling (e.g Active Support Notifications vs. gen_event)
* Instrumentation and Reporting
In this talk we start with the basic concepts of CoffeeScript and move on to the more powerful and fun features of the language. While we're looking at CoffeeScript we'll see how it relates to the Ruby code we write everyday. What do Ruby 1.9 lambdas and CoffeeScript functions have in common? Which of the two languages supports splats, default arguments, and ranges? The answers may surprise you.
There's a lot to Ruby and even experienced Rubyists are sometimes surprised to learn about parts of the language they haven't encountered before.
Do you really know all of the syntax Ruby can read? Are you familiar with all of the methods provided in Ruby's core? Have you used all of the roughly 100 standard libraries?
In this talk, I'll dig into the extras of Ruby and see if I can't turn up some features that you don't see all of the time, but that might just be handy to know about anyway. I'll make sure you come out of this able to impress your friends at the hackfest.
RubyMotion is a tool that lets Ruby developers write native iOS apps using the Ruby language. It's based on MacRuby which is an implementation of the Ruby language for Mac OS X. This talk will introduce RubyMotion with some simple live code demos and a twist of TDD. The level is introductory; you don't need to know Ruby or iOS to attend.
We all interface with Ruby libraries every day, so we all know what makes up a "good" Ruby API. But there is a lot more to a "good" library than just the API: proper logging, flexible configuration, a sane exception hierarchy, and useful documentation, just to name a few. How do we do these things properly? What pros/cons are there to different approaches? Unfortunately, no one really talks about these things, despite being very important to the overall feel of a library.
In this talk I'll share my knowledge of these things from being the maintainer of popular Ruby applications and libraries. I'll show you the idiomatic Ruby way to do logging, configuration, exception handling, and much much more. But don't worry, I won't just be preaching, I'll show you the reasons why these methods have become the community approved way of doing things.
We all know that Git is amazing for storing code. It is fast, reliable, flexible, and it keeps our project history nuzzled safely in its object database while we sleep soundly at night.
But what about storing more than code? Why not data? Much flexibility is gained by ditching traditional databases, but at what cost?
In this talk, I will explore the idea of using Git as a data store. I will look at the benefits of using a schema-less data store, the incredible opportunity opened up by having every change to every model versioned, and the crazy things that could be done with branching and merging changes to data.
I will also explore the challenges posed by using and scaling Git as a data store, including concurrent access and distributing load.
As developers and engineers we've spent a lot of time improving our tools to make our lives easier. Somewhere along the way, those improvements have introduced a new threat to our livelihood... Designers! Learn about how we've got ourselves into this place, why we have to lift our game, and why that can only be a good thing for everyone.
For many small sites with a minimal amount of complexity, a single rails application works fine. The problem is that as the application's complexity and scope grow, several problems arise. These include: heavy coupling, increased load and response times, and test complexity. All of these cause your feature development to slow considerably.
The concepts to solving these problems is relatively simple. The primary approach is extracting each concern in your application into its own service. The trick is extricating the data and classes when they are interdepend on the other aspects of the application.
We'll go over how this is done and what it meant when we had successfully teased the application apart. This approach was used on an application that collected, stored and managed millions of leads each month.
The Heroku application platform makes deploying, running and scaling applications incredibly easy.
Traditionally these apps have been Ruby web applications. But as both the platform and its users mature, we are seeing the complexity of hosted apps increase, with more complex infrastructure systems running on Heroku.
Today, nobody is more interested in running infrastructure on Heroku than Heroku itself, as self-hosting offers massive benefits and is a fascinating engineering puzzle to boot.
We will first discuss the concept of self-hosting and why it such an interesting computer science problem, and a vital property of many systems. Compilers, revision control systems and application platforms all exhibit similar properties of bootstrapping, cross-compiling, and avoiding circular dependencies.
Then we will take a look at the more interesting self-hosted components of Heroku such as the the distributed application compiler that used to be a server farm but now is little more than a Heroku app that can even compile itself for releasing new versions.
All of this will show how working towards a self-hosted platform results in comprehensive consistency assurance and gains in efficiency, noble goals for such a complex software system.
Sound familiar? The Rails ecosystem has grown in leaps and bounds, like the Java ecosystem did in its’ early days. So many languages, frameworks, plugins, engines, libraries and tools. So little time to deliver your new project.
It’s tempting to hire a rock star who knows absolutely everything to get your new project off the ground. You can also hire "consultants" to help fill in the holes in your team when taking your existing product to the next level. Or maybe just hire a whole bunch of people for cheap, and they’ll get the job done... But did you ever consider the untapped wealth of the team you already have?
In this session we’ll explore ways in which the average development team can explore, learn, teach, and grow, until the sum of members of the team is as great as any Consultant or Rockstar.