Videos provided by RubyFuza via their YouTube Channel
Hubot, GitHub's open source chat bot, is completely revolutionizing how we do ops at GitHub. Automating deployment, graphing, monitoring, provisioning, tweeting, and many other things with Hubot has enabled and enhanced our culture of remote work. We're standardizing how we interact with the applications and servers that run GitHub by continuously expanding our library of Hubot commands that any GitHubber can run in multiple Campfire chat rooms. Interacting with Hubot in the middle other of conversations has increased our awareness of what other GitHubbers are working on and the speed at which new team members learn common practices. In this talk, I'll give examples of how we deploy and interact with github.com via Hubot, describe benefits we've seen from this approach, and describe how you can bring ChatOps into your daily workflow.
Software licensing sets up rules for everyone to follow when contributing or using code. Some companies have specific policies on what types of licenses are compatible with their code base. Other companies put rules on their developers on how they're allowed to contribute code to software. Do you license your software? This talk will review some popular open source software licenses and considerations you should make before contributing code. It's good to be aware of these rules before you end up on the wrong side of a Cease and Desist order.
Ready, set, launch, (...crickets...). The tale of many a developer-turned-product-launcher, including me. But after a false start, I launched Classroom 7, a learning management system for trainers, which is now well on its way to paying the bills. Bootstrapping a product requires a bit of a multiple personality disorder - you've got to be a dreamer, engineer, critic, bank manager and sales exec all rolled into one. In this talk I'll share some of the lessons I've learned during the product launching journey and talk about some of the pitfalls that should be avoided when launching a product. Everyone has the ability to bootstrap a successful product, you've just got to start out right. This talk will set you on the right path.
Rails and Rack both have mechanisms to route requests. They are powerful, and offer some dynamic routing if you want to route within Rails. But what if you need to dynamically route requests to multiple Rack based applications? What if you want to control that routing dynamically with a database? Circuit allows you to do that. In this talk will explore the basics of Rack Middleware and Routing. Then we will show you how Circuit can help you to take Rack routing to the next level dynamically with lots of traffic.
This talk is about more than Unicorns. This is a scary talk about scary Ruby internals. Disregard the Unicorns, actually. There's a lot going on under the hood in MRI, YARV and Rubinius. The C and C++ layer that interacts with the OS is a tangly mess full of tricky bugs and arcane issues; the kind of issues that don't raise exceptions, but kill whole processes and make them bleed rainbows. Every time one of these "glitter bullets" kills a Ruby process, I shed a small tear: This is a talk about how we discover, tackle and fix these kind of issues at GitHub, to ensure our servers are always up and serving requests.
A brief presentation covering the primary mechanisms for achieving concurrency in Ruby. The differences and similarities of each will be touched on. At the end you may be lucky enough to understand which mechanism to use when (if you do, please be so kind as to explain it to the presenter :) ).
We all know the problem of the monolithic rails app, and we've all accepted the divine words of Service-Oriented Architecture. But what does your world look like once you get there? Or say, maybe, three-quarters of the way there.
Allow me to show you some of the mistakes we've made at Engine Yard on this path. It can be a bumpy road, but I promise you the destination is worth it.
How many companies are hiring Ruby developers right now? How many are finding qualified candidates? Why aren't workers swarming into our industry to fill up all these empty developer positions? Is learning Ruby really that hard? Why is learning Ruby so hard? Isn't it a language built by people for people? Shouldn't that be easy for anyone to pickup and use? Why isn't everyone building Ruby apps? I'm going to tell you. The good, the bad, and the goofy of trying to teach Ruby, Rails, and everything else we take for granted as RoR developers. There may even be a guest appearance from a real life Ruby Newbie to demonstrate!
JRuby runs on the JVM to bring high levels of performance and parallelism to your long running ruby code. TorqueBox is a performant and scaleable application server that reduces the complexity and dependencies of rack based web applications. See how these two tools can be used to simplify your ruby web development while delivering excellent performance under heavy loads with some real world examples.
Ruby is now 18 years old. It has become a very mature project and the developers that have been using it are a lot more mature now as well. Our community has long since crossed the chasm and we are in the early majority stage. This means that even though we have many people who are well versed in the language we are again having an influx of new people. I want to help those new people feel comfortable enough to believe they can learn and become just as mature as the oldies who are part of the community. Also, I want to educate the oldies on how they can better help out these newbies.
The Ruby community has become very much like any other close-knit community. We are very biased towards certain philosophies such as agile development, pair programming, and TDD. Some might compare our community to other close-knit organizations such as fraternities/sororities, athletic clubs and the freemasons. They all have very idealistic philosophies they run their organizations on. I want to show how we compare to these types of organizations. I want to highlight the good things we adopted from running our community this way as well as the bad. I want to show how we can improve and fix the bad habits so that we can create a more open community for new people to join and feel welcomed.
A brief case study on Service Abstraction. Taking a monolithic Rails app, separating concerns and growing out.
I will be discussing the decision behind the abstraction, how we approached it and where a handful of gems made the process a whole lot easier.
If you've ever done anything in ruby, you've probably used rubygems and rubygems.org to search or install your favorite gem. On October 17, 2012, rubygems.org went down. A Dependency API was built to be used by Bundler 1.1+ to speed up `bundle install`. Unfortunately, it was a bit too popular and the service caused too much load on the current infrasture. In order to get rubygems.org back up the API had to be disabled. You can watch the post-mortem, http://youtu.be/z73uiWKdJhw, for details.
Members in the community stepped up and built a compatible Dependency API service called the Bundler API. Working with the rubygems.org team, we were able to bring the API up for everyone within a week. In this talk, I will cover the process we went through of extracting the API out into a separate Sinatra app that now runs on Heroku. I'll go over how the API works and how Bundler itself uses it. Since we don't have direct access to their database, we needed to build a syncing service to keep our local cache up to date. We'll discuss the original sequential implementation of the sync code and how we improved performance through the use of a consumer thread pool. The sync time down was cut from 16 mins to 2-3 mins. Next, we'll talk about the productization steps we took for visibility to make sure the app is performing well.
We're prototyping a replay service, to replay production traffic to different Heroku apps. With this we can compare the performance between the current MRI app in production and the same app running on JRuby. This will also allow us to test any changes/features against real production load. We'll go over how to set this up.
Functional Programming is more than a set of language features. It's a style of thinking, a way of doing things.
Ruby gives us access to some aspects of the Functional style through lambdas, blocks, procs, and array iterators.
But the most profound way in which Functional thinking can change your Ruby day comes down to a core issue of Functional Programming: "side-effects". Ruby places no restriction on leaving side-effects - it comes down to the choice (and then discipline) of the Rubyist to refrain from doing so.
Side-effect-free code is more easily testable, and more predictable than side-effect-ridden code.
In this talk I'll show you some of the many ways in which side-effects cause you pain and suffering, and techniques and strategies of leaving less of them in your wake.
Since we are using these functional tools, we really do need to understand this world. So, what does this functional world look like? How are functional minds wired?
In this talk, I will take you on a whirlwind tour of functional programming concepts. You will see lots of code snippets in lots of different languages. My objective is simple - a tour guide view that will point out places of interest that you can explore at your leisure. In the end, I hope we will make smaller messes.
We all agree that tests are important. As a developer, coming into a new project with good tests makes you immediately feel more confident about making changes. But how do we ensure that our test suite consistently adds that value over a long project? We're going to look at best practices using RSpec and how applying a few simple rules and best practices can improve the overall quality of your application.
Writing modern web applications requires a ton of JS, and somewhere in that JS lies some application logic (we're not just talking DOM manipulations here). If you require that same logic on the server-side for say, generating reports, what do you do? I'll show you how ValuationUP.com pushes the single responsibility principle to the max by "embedding" V8 into our report generation code so the same JS that powers our Backbone.js frontend powers our PDF's generated by Prawn.