Add an eventSessions at RubyConf 2011 about Ruby
Your current filters are…
- Topic: Ruby
Thursday 29th September 2011
-
Keynote: Ruby Everywhere
Keynote by Matz
-
Big Data Enterprisy Analytics App and Ruby
by Amit Kumar
The enterprise is a closed ecosystem with its own rules. Internet is all about openness and freedom. Solving the `Big Data` problem for an Enterprise requires:
1) Maintain large amounts of structured and unstructured data
2) Complying with internal technical standards and enterprisy architectural guidelines
3) Local as well as global enterprise regulations etc.I would like to share how Ruby helped in building a scalable Analytic application. The application uses OLAP Cubes and deals with data slicing/dicing.
-
Persisting Relations Across Time and Space
Entities and their relations are the backbone of many Ruby applications – from trivial, one-off commandline utilities to full-blown social network websites. The good old relational databases, while showing extreme abilities in both adaptation and survival, are no longer the obvious choice for persistence – and sometimes obviously not an ideal one.
This talk discusses various entity/relation modelling approaches and different persistence techniques – from rigid schemas in suits to collections of hippie free-form documents; from good old (transactional!) PStore through join-table-happy RDBMSes and muscle-flexing NoSQL hools to (social!) graph databases, waiting patiently for broader recognition and prime time.
Quite a few interesting Ruby libraries for gluing all this together are also pondered upon – from world-class champions like Active Record or ARel to less known gems like Candy and Ambition.
-
Writing Solid Ruby Code
by Jim Weirich
Do you always seem to be fixing bugs in your software project? Are you spending more time fixing defects that actually implementing new behavior? If so, this talk is for you.
In the mid-90s, Steve Maquire wrote a book that strongly effected the way I developed software. Primarily writing in C and C++ in those years, the struggle to deliver bug free software was especially a challenge. In the book "Writing Solid Code", Steve gives sage advice on the problems of developing large software projects and the challenges that go with making sure your softare actual does what you think it should.
Although as Ruby developers we are no longer using C to deliver our large projects, the challenge of writing solid, reliable code is still before us. Based on Maquire's advice and my own years of Ruby experience, this talk will show developers tools, techniques and practices that they can use to improve their software and begin writing solid code.
-
Exceptional Ruby
by Avdi Grimm
You know how to raise and rescue exceptions. But do you know how they work, and how how to structure a robust error handling strategy for your app?
This talk starts with a technical deep dive into Ruby's exception facility, covering features, tricks, and gotchas you never knew about. You'll learn how to retry failed operations; how to override "raise" for fun and profit; and advanced techniques for matching exceptions in rescue clauses.
From there, we'll move on to patterns and guidelines for structuring a robust, failure-resilient codebase. We'll look at strategies for avoiding failure cascades; how to characterize and verify the exception-safety of critical methods; and alternatives to raising exceptions for when "fail fast" isn't the right answer. Finally, you'll learn about the three exception classes every app needs.
-
Why You Don't Get Mock Objects
Although the Ruby community has embraced TDD like no other community ever has, we have always looked at mock objects with disdain, and perhaps even a little hatred. I've heard conference speakers call them "Wastes of time", "Scams", and even "Testing Heresies". Why would anyone have ever developed these pieces of junk?
In reality though many in the agile community have embraced mock objects within their testing cycles because they have found using these fake objects improves the design of their systems. But why not Rubyists? Most Rubyists don't get mock objects because they don't understand their history or their creators intent. They try to fit them into their current workflow without understanding them, and find them unhelpful and stupid. After all, almost all of the good literature on the subject is written in Java, and we know how frustrating it is to read Java when your used to Ruby.
As such, this talk will attempt to demonstrate in Ruby the usefulness of mock objects, and how to use them to improve the design of your system.
Specifically the following will be covered:
- Why do we need mock objects (Following the 'Tell, Don't Ask Principle')
- Why you should only mock objects you own
- Why you shouldn't use mocks to test boundary objects like external API calls
- Why you should mock roles, not Objects
- Why you should only mock your immediate neighbors
- Why listening to your unit tests will tell you about design problems in your code
-
"Algorithms" is Not a Four-Letter Word
by Jamis Buck
Why does the word "algorithms" convey such a sense of musty dustiness? It doesn't have to! Implementing algorithms can be a fantastic way to grow your craft, practice programming idioms and patters, learn new programming languages, and just generally have a good time! Come learn how to generate, navigate, and solve MAZES in a variety of ways. Be prepared to drink from a firehose as I walk (run?) through eleven maze generation algorithms and several ways to solve mazes, in just 45 minutes! You'll never think of algorithms the same way again.
-
Parallel worlds of CRuby's GC
CRuby adopts Mark Sweep GC Algorithm now.
In my presentation, I talk about Parallel Mark Algorithm for CRuby's GC that improves Mark.
Parallel mark divides a mark phase into a plurality of threads and it parallely execute.
Recentlly, 8 core computers are not rare.In such an enviroment, GC will be speed up, if it distribute tasks to each core.
I'll talk the parallel mark algorithm and implemention, result of benchmark.
-
So You Think You Can Code: Part Deux
by Aaron Patterson, Evan Phoenix, Ben Bleything, Yosef Mendelssohn and John Barnette
The Fabulous Five are back! Last year we blew your mind. This year we will blow your heart. Join us as we put on our robes and wizard hats and enchant you with witty banter, amusing anecdotes and live Q&A. We'll cover topics ranging from "best ruby interpreter" to "best ruby interpretive dance". Featuring Aaron "The Kissing Bandit" Patterson, Ben "It's Bleything, not Bleything!" Bleything, Yosef "Totally Great" Mendelssohn, Jon "The Bear Brogrammer" Barnette, and Evan "Totes Not Creepy" Phoenix. Moderated by Rein Henrichs.
-
Advanced EventMachine
We use EventMachine heavily in production. It is handling uploads to S3, managing thousands of messages a second or distributing agent workload.
This taught us a load about EventMachine and some weired corner-cases. I want to about such advanced EventMachine topics and shared some use-cases and experiences from the trenches.
-
Evented Telephony Application Design with Adhearsion
by Ben Klang
Adhearsion is a new way to write voice-enabled applications. It's not just an API or library -- it's a fully-featured framework, the first of its kind, designed for maximal code reuse and intuitiveness. Building on ideas learned from existing Ruby web development frameworks, Adhearsion brings test-driven development, ActiveRecord models and the full power of the Ruby language to the world of telephone applications.
This talk covers Adhearsion’s powerful eventing interfaces for call control. Rather than handling each call session in a linear (and often blocking) sequence, we can react to events as they happen during the call, such as code reacting to the active speaker in a multi-channel conference, handling mid-call DTMF keypresses or manipulating state as calls are set up and torn down.
-
How Getting Buff Can Make You a Better Rubyist
by Rob Sanheim
Two years ago, I was about to turn 30. I was working constantly. And I was in the worst shape of my life. I weighed almost 270 pounds. My back, hands, and wrists ached constantly from repetitive stress and poor posture after working long hours. A full eight hour day or programming left me exhausted and irritable.
I got on a plan to get in shape and lose weight, and given enough time and good habits, it worked. I lost a ton of weight and feel great. Along the way, a funny thing happened: I became much more effective as a developer, getting more done in less time. Work is more fun, my repetitive stress injury is gone, and eight hours of pair programming doesn't destroy me like it used to.
This talk will discuss pragmatic ways to improve your health, reduce stress, and improve focus, all without a gym membership or dreadful treadmill sessions. We'll touch on modern science that demonstrates the importance of the mind/body connection, and cover some hacker friendly diet and exercise plans.
-
LocalCommunity.Build, :through => Code Retreats, Bugmashes & more
The talk will focus on <= 1 day length events that any Rubyists can organize in their locality to nurture and grow a vibrant ruby community.
Specifically, the talk will explore in detail two such events - Code Retreat & Rails Bugmash, and will be based on my experience in organizing Code Retreats in Boulder (Feb 2011) & Fort Collins (June 2011), and Rails Bugmashes in Boulder and Bangalore (both in May 2011).
-
Better Than ROT13
We use encryption every day, from SSL to SSH to passing notes to your crush during Social Studies class. But how does it actually work? I'll avoid most of the math but cover the concepts of both symmetric and asymmetric encryption, including hashing and signing. I'll also show how to use OpenSSL from inside ruby and show off the idkfa gem, a library to securely store sensitive information into your code repositories.
-
Keeping Ruby Reasonable
Pop quiz, hot shot! What is the value of this Ruby expression: "2 + 3"?
What if I told you that somewhere earlier I had done this: "class Fixnum; alias :+ :*; end"? Changes everything, right?
We're all familiar with Ruby's open classes. For many of us, they're one of the facets of Ruby that make it so much fun to work with. However, Ruby treats bindings as first class objects, and they are, similarly, open. This can lead to problems. What sorts of problems? Well, effectively, the only way to know what a Ruby program will do is to run it. Stated another way: it is impossible to reason about Ruby.
Now, this may not seem like such a big deal for the seasoned Rubyist. So long as we're responsible in how we write our code and make sure not to do anything too crazy, we can have a pretty good idea of what any piece of code will do ahead of time. Unfortunately, compilers and runtimes can't rely on "responsible" programmers and having a "pretty good idea" of what code will do just doesn't cut it for a VM. As a result, method caches get invalidated far too often and whole classes of common optimizations do not work with Ruby.
So, what's a programming language to do? Luckily, Ruby is not alone in facing this dilema. The Scheme community has been confronting similar issues from the very beginning, and in the R5RS and R6RS reports, they outlined a solution. This talk will take a look at what makes first-class environments and "eval" so problematic, and what lessons Ruby might learn from Scheme in how to be more reasonable.
-
Pure Ruby GUI
by Uncle Bob Martin and Micah Martin
Father-son-team Bob and Micah Martin open the hood on a pure ruby GUI tool they built to monitor their website, cleancoders.com. During this whimsical tour Bob and Micah will reveal how they made use of Limelight, along with a simple web service layer, to build a desktop GUI that provides vivid realtime information on usage of their site.
-
Powerful (but Easy) Data Visualization with the Graph Gem
by Aja Hammerly
Many projects involve large datasets. While humans are master pattern matchers, trying to find patterns and issues by looking at reams of text is hard. Sometimes you just need the 30,000 foot view but creating diagrams by hand is time consuming and prone to error.
The graph gem makes it quick and easy to create visualizations of your data. In this talk, we'll learn how to use nokogiri and graph to get data out of an XML file and into a format where you can see relationships and patterns. We'll also see how color coding and clustering can emphasize the patterns in your data. Many of the examples will come from my work with adaptive education apps.
Friday 30th September 2011
-
Ruby Software Continuously Delivered and Exhaustively Explained
by Srushti Ambekallu and Brian Guthrie
The Ruby community has driven a lot of technical innovation in deployment and configuration management over the last few years, and so the idea of delivering high-quality software rapidly should be familiar to many of us. But although many of our tools are state-of-the-art, our practices could stand a bit of scrutiny. Your friendly neighborhood server admin probably isn't thrilled with running RVM or compiling gems in production, and your nervous project manager is asking why deploying constantly is such a great idea anyway. Won't you just stop coding for, like, five minutes and click around the app for a bit, just to make them feel better?
In this talk, the maintainers of two competing continuous integration servers at two competing shops lead you on a Socratic tour of the past, present, and future of continuous delivery as seen through an Agile Ruby lens. We'll talk about the changing deployment toolchain, the difficulty of evolving code as it's deployed, and how to coach your developers, testers, and client to be "production-ready, any time."
-
Message in a Bottle
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 four major Ruby implementations - 1.8, 1.9, JRuby and Rubinius, focusing on their dispatch. From look-up tables and call site caches, to inlining and what on earth is invokedynamic? Expect C, C++, Java, and, of course, Ruby code. But fear not, all will be explained!
-
Services Inception with Ruby
by Dave McCrory
Ruby code creating services for it to then consume aka Service Metaprogramming
A very large number of Ruby apps are deployed in hosted environments. Many of these hosted environments offer both internal and external services with APIs that your Ruby app can consume. The problem is that the use of these services often requires provisioning tasks for each service and the service must always be there or the app will fail.
This session will show Metaprogramming Ruby code and a RubyGem for provisioning/de-provisioning, binding/unbinding, sharing configuration state, and more. This allows your application to create a Redis or MySQL instance only if needed (say on initial startup) or bind to a specific service, but only if/when it is present. This approach eliminates many of the forgotten steps during deployments and makes it easier to understand what your Ruby code really depends on because it is all encapsulated in the application’s code itself!
-
The Return of Shoes
It's been two years since _why the lucky stiff has departed Ruby. His work, however, carries on. Shoes was one of _why's most ambitious projects, and a tiny but scrappy team has kept Shoes alive.
If you haven't heard of Shoes, it's a GUI toolkit for Ruby. Most of these are simply bindings to toolkits written in other languages, like QT or Tk. Shoes is native to Ruby, so it uses Ruby-only features heavily, such as blocks. Shoes also includes packaging functionality that allows you to distribute your apps on Linux, OSX, and Windows.
In this talk, Steve will cover the basics of building applications with Shoes, the challenges of maintaining a large polyglot project with an absent inventor, and what's in store for the future of Shoes.
-
Ruby OpenSSL: Present, Future and why it matters
by Martin Boßlet
We will start with an overview of what exists today (Ruby 1.9.3) in Ruby's OpenSSL wrapper and how and where you can use it and why you should. After this brief introduction we will encounter new features that could find their way into future versions of Ruby OpenSSL.
Among these is OpenSSL::ASN1::Template, a DSL that allows parsing/encoding ASN.1 structures with simple declarations that look similar to ASN.1 itself. We will find out why I finally decided to ditch a working implementation in pure Ruby just to replace its majority with C code - including the lessons learned about performance.
Another feature would be XML signature support (OpenSSL meets Nokogiri) and a clean solution to finally stop people from using OpenSSL::SSL::VERIFY_NONE by making certificate validation less of a pain while still improving the security.Finally I'd like to revive a concept that never really found broad acceptance although it would largely increase the trustworthiness of our beloved gems - *digitally signed* gems.
-
The Secret Life of Ruby: Warrior With A Cause
Ruby has demonstrated itself to be an extraordinary tool for the rapid development of prototype systems in an environment of unclear, undefined, ill-defined, missing requirements. As a dynamic language its ability to rapidly morph based upon the needs of the moment is remarkable. The way that it can be used to hide complexity via domain specific languages is unparalleled.
This session reviews 5 years of success using Ruby within a research and development lab of a major USA defence contractor. Lessons learned, evolved patterns and suggestions for future improvements are on the agenda.
There are movies. Bring your own popcorn.
-
Lessons Learned While Using Ruby's MP System to Model a 2,500 Year-Old, Dead Language
I have completed a second major release of a library that fully conjugates Classical Latin verbs in each of their 133 froms * 5 standard paradigms.
Owing to the irregularity of human communication, modeling the provision of unambiguous answers (return values) to ambiguously asked things (flexible / incomplete method calls) might have required hundreds, if not thousands, of method definitions or static values entered in a database.
But what if heuristics could be given to a Ruby class such that it "thought" as language learners are taught to think? What if it could be taught to be flexible in respecting the ambiguous calls given and to still give precise, correct answers back - as human language learners are capable of doing? By adopting this design paradigm code could become leaner and more reflective of human cognitive process.
Thankfully for Rubyists, this is not a dream, this is reality. Our programs can operate more intelligently, more heuristically, and more insightfully. We can save ourselves days of development time by integrating the next tier of metaprogramming patterns I seek to demonstrate. This is perhaps what makes Ruby so unique, so mysterious, so enticing and so special.
-
The Well-Grounded Nuby
An examination of a large handful of features and characteristics of Ruby that, once understood, provide a solid foundation for continued learning and/or mentoring
-
Implementation of Ruby 1.9.3 and later
by Koichi Sasada
Maybe, Ruby 1.9.3 will have been released at the time of RubyConf2011. In this talk, I will introduce the news about this latest release. This is not a language features, but a implementation features. I will also introduce other developing features which can not implement on 1.9.3 in time. Moreover, I will introduce our research activities such as real-time profiler, pragmatic compilers and our approach to introduce parallel execution into Ruby - MVM.
-
Parallel Testing World
Ruby (MRI) has an unit-testing library, 'test/unit'. This is used for ruby's `make test-all`. In February 2011, I committed a patch ("parallel_test") that allows us to run multiple Test::Unit::TestCase-s at the same time.
Because of this patch, ruby's `make test-all` can run tests faster. This patch also affects to existing tests using `test/unit`.
In this talk, I take you into the parallel testing world. We'll talk about general parallel testing, benefits of parallel testing, multi-threaded or multi-process, etc. Then talk about the patch, the story of making the patch and describe how the patch works.
-
Test-drive the development of your command-line applications
Rubyists love testing, and test-driven-development is becoming THE way to write code. But, do we do this with our command-line tools? How DO you write a test that your awesome application cleans up its temp files? How does one make a failing test for a missing command-line option? What's the easiest way to check our app's exit codes? This talk will answer these questions with some real-world examples. We'll talk briefly about the challenges particular to testing command-line apps, and then dive into some code where we'll show off techniques for organizing code for testability, tools for interacting with the filesystem, and how to create full-blown acceptance tests for your command-line app. In no time, you'll be able to write your command-line apps the same way you write your other code: test-first.
-
KidsRuby: Think Of The Children!
by Ron Evans
Forget about JRuby. MacRuby? Forget it. Forget even Rubinius. As cool as each of them is, they are old. Like, you know, for adults. Introducing the real future of Ruby: KidsRuby... because the future is about the kids! http://kidsruby.com
KidsRuby was born as a fresh approach to the most important problem we as an industry face: who is going to maintain our code in its old age? Most of us in the Ruby community are aware that it is a great time to be a programmer. However, it's not so great to be some company trying to find an experienced programmer to hire. And the problem is only going to get worse, since the state of computer programming education is the US and UK is down, even as demand increases. Like becoming a master musician, master programmers are not created quickly. Many of the best programmers today started when they were young. There have been a number of excellent contributions for teaching kids to program using Ruby. The most famous Ruby environment for kids being Hackety-Hack, from _why the lucky stiff. However Hackety-Hack is showing its age and inherent limitations, especially if you want to use it with any normal gems, or want to contribute to it. Even the 1.0 release suffers from these problems. KidsRuby is a real Ruby, so that kids are not treated like second class citizens just because they are learning Ruby. It helps to solve a number of the biggest technical problems with teaching Ruby to kids. In 30 minutes I will share not just the technology used to build KidsRuby, but more importantly the social glue needed to help start out the next generation of programmers with the language we all love.
It it time for a general call to arms to the Ruby community. We all need to get serious now about training the next generation of hackers. After all, think of the children!
-
Nikita: The Ruby Secret Agent
by Brian Ford
Ruby, the beautiful, malleable language with a lovely object model and great reflection capabilities... and almost zero tools. If I had a coin for every time some Smalltalker gloated about the Smalltalk class browser or some bloke bragged about the Java refactoring tools, I could start my own bitcoin.
Building great tools for Ruby requires great support for Ruby itself. The problem is, there is often a giant molten blob of C or Java code in the Ruby implementation with a thin veneer of "Ruby" method bindings. Rather than supporting great Ruby tools, that effectively prevents building them. How does one browse core library classes like Array when the code is not even Ruby?
Rubinius addresses this situation on two levels. Firstly, the Rubinius core library is written primarily in Ruby. Curious what that Array#[] method does? Just pull up the Ruby code and take a look. Rubinius also creates first-class Ruby objects for Ruby infrastructure. When a method is defined, there is actually an object, CompiledMethod, that you can lay your hands on, inspect, and manipulate like any other Ruby object. Secondly, Rubinius builds essential tools into the virtual machine. There is a built-in debugger, profiler, and also stats for the garbage collector. Further, Rubinius has a facility, named Agent, for querying and controlling the virtual machine.
Nikita is a top-secret project to create a set of simple, integrated applications that use the Rubinius facilities to build tools for Ruby. The interface is a Sproutcore application, which enables using the tools remotely, for example, to monitor servers.
In this talk, we'll look at the Rubinius features that support writing tools for Ruby and examine how those features are used in Nikita. Then we'll set Nikita loose on some problem code. It might get bloody.
- 1
- 2
RubyConf 2011
United States United States, New Orleans
29th September to 1st October 2011
Calendar subscribe
Schedule incomplete?
Filter by Day
- Thursday 29th 17
- Friday 30th 17
- Saturday 1st 13
Filter by coverage
- Video 45