Tags

101 videos are tagged with ruby

2348 mwrc2013 ruby at github thumb 0001 thumb
Rating: Everyone
Viewed 3,091 times
Recorded at: April 5, 2013
Date Posted: April 29, 2013

GitHub loves Ruby. Many of our products, tools and infrastructure are built with Ruby.
In this talk, we will look at the libraries, practices and conventions that GitHub uses with Ruby. We will survey all of the repositories maintained by GitHub to get insight into how it is used, and we will also examine some of the areas where we opt to not use Ruby.

Vlcsnap 2014 12 22 15h16m55s117 thumb
Rating: Everyone
Viewed 7,342 times
Recorded at: November 17, 2014
Date Posted: December 22, 2014

712 rubyconf2011 github flavored ruby thumb 0000 thumb
Rating: Everyone
Viewed 6,720 times
Recorded at: October 1, 2011
Date Posted: December 3, 2011

Someone once told me that software development is a constant battle against complexity. Over the past three years we've built several large systems at GitHub and if anything, that saying is an understatement. Things like tight coupling, insufficient testing or documentation, lack of versioning discipline, and underspecified design documents can easily lead you down a path of ruin. In this talk I'll cover many of the techniques we use at GitHub to defend against complexity in our Ruby systems, including Readme Driven Development, Semantic Versioning, TomDoc, Git/GitHub workflow, modularization, metrics, and exception reporting.

Tom preston thumb
Rating: Everyone
Viewed 702 times
Recorded at: September 17, 2011
Date Posted: December 17, 2012

It has been said that software development is a constant battle against complexity. GitHub has built several large systems over the past three years, all while engaging in the proverbial battle against complexity. Things like tight coupling, insufficient testing or documentation, lack of versioning discipline, and underspecified design documents can easily lead developers down a path of ruin. This talk will cover many of the techniques GitHub uses to defend against complexity in Ruby systems, including Readme Driven Development, Semantic Versioning, TomDoc, Git/GitHub workflow, modularization, metrics, and exception reporting.

Tom Preston-Werner is a cofounder of GitHub, the social coding phenomenon that has captured the imaginations of hackers around the globe. He is also a serial entrepreneur having sold Gravatar to Automattic and run a web/graphic design firm, Cube6 Media, out of San Diego.z

1193 rubyconf2008 ruby macros thumb 0002 thumb
Rating: Everyone
Viewed 954 times
Recorded at: November 9, 2008
Date Posted: September 22, 2012

1197 rubyconf2008 iron ruby demonstration thumb 0003 thumb
Rating: Everyone
Viewed 887 times
Recorded at: November 9, 2008
Date Posted: September 22, 2012

D1t2p1 ruby and electronics preview thumb
Rating: Not yet Rated
Viewed 1,467 times
Recorded at: November 2, 2007
Date Posted: September 22, 2010

1295 rubyconf2012 change your tools change your outcome the next frontier of deployment thumb 0003 thumb
Rating: Everyone
Viewed 1,964 times
Recorded at: November 2, 2012
Date Posted: November 18, 2012

When you type “cap deploy”, “ey deploy”, or “git push heroku master” your intent is to deploy your local application source to your running system on the Internet. That seems to be the point - you changed your code, and you want to Just Ship It. But what is your actual objective? Is it really to just “deploy app code changes”? Is this “app-centric” view and user experience satisfactory?

Code deployment is your intent on some occasions. On others you want to change your production environments for applications, or change scale attributes of your system, or change how applications and services within a system communicate with each other, or with remote services (such as facebook).

Is “app-centric deployment” the best mental model and toolchain for shipping changes to productions systems? Or is “environment-centric” or “node-centric”, enabled with frameworks like Chef or Puppet, the most powerful & effective model of the system to allow you to deploy and manage change?

Or perhaps we should describe the entire system - all the apps, all the system dependencies, all the interconnections, all the scale attributes - and command it to come into existence? To command the system to go from nothing to v1 to v2 to v3, where each version includes changes in attributes of the system.

Where should configuration/manifests/attributes go? Source code files in the config folder? PaaS configuration or environment variables? Or should components of a system dynamically discover information about itself and configure itself?

Perhaps we need the benefits of a “system-centric” build toolchain, with an “app-centric” user/developer experience to trigger deploys, with a “node-centric” experience for sysadmins.

In this talk, we will reflect on the current state of deploying production systems, including build/deploy toolchains, and continuous deployment. We’ll look at the attributes of a complete system, how we explicitly or implicitly describe them and their relationships, and how to orchestrate changes in the system - from app-centric, node-centric and system-centric views.

Let’s discuss the difference between deployment in month 1 and living with your system for the next 59 months.

Work thumb
Rating: Everyone
Viewed 214 times
Recorded at: February 8, 2013
Date Posted: June 6, 2014

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.

Jim gay thumb
Rating: Everyone
Viewed 11,245 times
Recorded at: November 19, 2014
Date Posted: December 2, 2014

Messy code often begins with a simple "if". Continuing down that path is a road to ruin, but there's a simple way to avoid it. East-oriented Code is an approach that helps you follow Tell, Don't Ask. It guides you away from Feature Envy and toward better encapsulation. See before and after code and walk through easy to repeat steps that will make your Ruby programs better and easier to maintain.