Users have come to expect state-of-the-art search features in every part of their online experience. The good news for developers is that features like autosuggest, spell-correct, and personalized search are becoming easier to develop thanks to services like Elasticsearch. Integrating Elasticsearch into ruby apps is now relatively straightforward thanks to the Tire wrapper library. The talk will examine how to build an Elasticsearch cluster, create indexes, load data, and format and execute robust search features using the ruby Tire library.
One strength of the Ruby community is the simplicity of sharing code via gems. When a gem is popular enough, it can even develop an ecosystem of additional gems that build on it.
But extending a gem that wasn't built with that flexibility in mind isn't always easy. This talk highlights tips and techniques for making your gem simpler to plug into, and avoid mistakes that will have devs cursing under their breath.
We'll cover the highs and lows of interacting with others gems, from configuration to documentation and everywhere in between.
Acute Zombielepsy has broken out, and the CDC has turned to you to store the first one million records of victims in the U.S. including the subject’s name, DNA sample, geo, etc. You must store this crucial data in a resilient manner in case one or more data centers are compromised by the outbreak. The CDC also needs to query the data in several ways; for example, they want to see the outbreak on a map to visualize geographic clusters. Naturally, you turn a fault-tolerant NoSQL database to store this data. But since you come from a relational background, you find it difficult at first to model the data properly for the types of queries that the CDC wants to run. Learn about advanced data modeling on a key-value database in Ruby -- distributed indexes, convergent data types, geohashes, and more -- on a truly fault tolerant database infrastructure. Keep calm; the fate of the human race depends on you.
Rubygems.org provides every Rubyist with an amazing service: all the libraries in the Ruby world. As amazing as that is, installing gems can be a time-consuming and even error-prone process. (Just ask the Travis guys.) In this talk, you'll learn about the recent dramatic changes in Rubygems and Bundler to improve speed and reliability by rewriting the Rubygems client/server architecture. I'll show how the new system caches more information, makes fewer requests, and takes less time to install gems. Finally, I'll cover how the changes allow worldwide mirrors of rubygems.org, improving things for Rubyists around the globe.
A couple of years ago, a client asked me to build a recommendation engine for them. Coming into this with a minimal knowledge of statistical math, I ultimately built a relatively simple recommendation engine in Ruby. The design made heavy use of Redis Sets, Lists, and Hashes in order to greatly reduce the number of SQL queries to provide recommendations.
This talk will be a case study discussing the object-oriented considerations in designing a scalable service, how Redis was a good fit for the project, and some of the painful lessons that I learned along the way so that you don't have to repeat them.
There are currently a great crop of tools out that for doing Ops in Ruby, but when you need real certainty about your infrastructure for a specific provider the only way to test is through provisioning actual resources and making assertions about them. Currently the tools aren't quiete there.and you might be better off rapidly developing your own deployment framework with integration testing in mind. This talk will discuss what we've done at CardSpring to develop our own Ops as a Service and provide developers with a stress free deployment API using Ruby, Chef, and AWS and backed by full RSpec coverage.
In this detective story we'll start by identifying and fixing easy performance problems in Ruby, before working our way down to the guts of the interpreter itself. Using concrete examples from RSpec and CRuby we'll cover all the necessary tools including benchmark, ruby-prof, gnuplot, and more, and show how you can tie them all together to solve real problems yourself.
We are working on development of Ruby 2.1 to improve its quality. Ruby 2.1 will be released with several new features, especially with new *generational* garbage collection. In this talk, I will show you a brief introduction of new GC algorithm and other new features of Ruby 2.1.
Not sure where to cluster or where to classify? Have you seen a linear regression lately? Every wanted to take a look into machine learning? Curious to what problems you can solve? Using Ruby to become familiar with machine learning and data-mining techniques is great way to get acclimated before diving in with both feet.
Pry is a featureful irb replacement that provides Ruby programmers with a seriously souped-up REPL.
Using some real-life examples, I'll explain how to use Pry to program more effectively.
We'll start with the basics of exploring libaries and experimenting with code at lightning speed. Then we'll move up a level and discuss how to dig into, debug and even modify existing programs. Finally we'll cover a few of the plugins that make Pry a truly indispensible tool.
Ruby applications are becoming more complex and unwieldy (think MonoRails). An increasing number of us are trying to address this by separating our apps into gems without knowing best practices on how to write APIs or how to manage dependencies and versioning. The discussion we often have around good APIs should not stop with Ruby OO design, but should also consider the public APIs of gems.
This talk is intended for gem authors and users. It will share though many practical examples using the Ruby driver to MongoDB 1) Principles of good gem API design, 2) How to make your gem API optimal for users and how to best use the API of a gem, 3) Guidelines for introducing and anticipating gem API changes and managing dependencies.
Learn about the genes, which controls everything you do and find out how you can ease the task of your similarity with a salamander using Bioruby!
Bioruby is great Bioinformatics tool which helps to process biological data and analyze it. 5 years after ruby programming language came into vogue(1995), bioruby came into existence in 2000, both developed in Japan. BioRuby project provides an integrated environment in bioinformatics for the Ruby language. This project is supported by University of Tokyo (Human Genome Center), Kyoto University (Bioinformatics Center) and the Open Bio Foundation.Welcome to the ruby in the living world, integrating ruby with the Bioinformatics and have fun.
On one hand we have the Bioinformatics, the large database of the huge genome sequences, the search algorithms to search the gene similarity between different organisms, gene-mutations using the popular search tool Blast, Fasta etc. BioRuby helps us to do the same searching thing using ruby programming language. As ruby is a pure object-oriented programming language(everything in ruby is an object) and being a easy to read and write, it's fun to use here without being lost in the plethora of genomic data.
One of the greatest contributions from Bioruby is Biogems, which like any other rubygems helps to perform modular approaches in order to perform specific functionality. One such gem is bio-ucsc-api gem, which helps to fetch record from UCSC DB and the best part is the gem has been implemented using the Actice Record Framework thereby easing the record fetch, instead of complex sql queries. We explained the basic concepts of Gene, DNA. RNA, Amino-acids, Human Genome Project and how these huge data are stored and analyzed by the famous Bioinformatics tools like BLAST, Fasta and how Bioruby interacts with the different biological databases like Genbank, Swissprot etc.
Debugging is an art. And to be an effective artist, an artist must be intimately familiar with their tools. In this talk, we'll start gently and finish strong to ensure that there's something for everyone. We'll cover when to use a debugger, which debugger to use, and how to use the debugger, and how to quickly configure your debugger for maximum utility. We'll touch briefly on pry and why pry is not a debugger, except when it is.
Developers are always looking for ways to boost productivity. Effective debugging allows one to more quickly discover inaccuracies between our expectations and how the software actually behaves.
Concurrency and parallelism in Ruby are more and more important in the future. Machines will be multi-core and parallelization is often the way these days to speed things up.
At a hardware level, this parallel world is not always a nice and simple place to live. As Ruby implementations get faster and hardware more parallel, these details will matter for you as a Ruby developer too.
Want to know about the pitfalls are of double check locking? No idea what out of order execution means? How CPU cache effects can lead to obscure crashes? What this thing called a memory barrier is? How false sharing can cause performance issues?
Come listen if you want to know about nitty gritty details that can affect your Ruby application in the future.
Reading of the CRuby (MRI) source code provides unparalleled insight into the Ruby language. During the talk we will add new native Graph data type to CRuby. The new Graph data structure will be simple but on par with other native types such as Array or Hash. This talk will demonstrate that it is easy to experiment with CRuby and extend it in C. We will experience the speed advantage of using C to boost Ruby performance. We will implement a few of the greatest hits of graph algorithms: Breath First Search, Dijkstra, and Minimum Spanning Tree.
Many of us approach regular expressions with a certain fear and trepidation, using them only when absolutely necessary. We can get by when we need to use them, but we hesitate to dive any deeper into their cryptic world. Ruby has so much more to offer us. This talk showcases the incredible power of Ruby and the Onigmo regex library Ruby runs on. It takes you on a journey beneath the surface, exploring the beauty, elegance, and power of regular expressions. You will discover the flexible, dynamic, and eloquent ways to harness this beauty and power in your own code.
JRuby is a fast, compliant Ruby implementation which can make use of many features of the Java platform. What more is there to do? Can it be made faster? Will it ever load faster? Any plans on making cross-implementation native C extension API?
This presentation will answer questions like this and give some examples of exciting future projects involving JRuby. If you want a good insight into where JRuby is going then this talk is for you.
Partial evaluation is a powerful tool for timeshifting some aspects of a program's execution from the future into the present. Among other things, it gives us an automatic way to turn a general, abstract program into a faster, more specialized one.
This math-free talk uses Ruby to explain how partial evaluation works, how it can be used to make programs go faster, and how it compares to ideas like currying and partial application from the world of functional programming. It then investigates what happens when you run a partial evaluator on itself, and reveals some surprising results about how these techniques can be used to automatically generate compilers instead of writing them from scratch.
Just as Ruby is great for getting a new web project off the ground and into production, Ruby is equally awesome for quickly building games up from scratch and continuing to iterate on them. This talk explores the basics of how computer games work, shows the tools available for building games in Ruby, and has a live demonstration of creating a simple game.
Service-oriented architecture (SOA) is an evolution of distributed computing based upon the request/response design pattern (aka RPC) for communication between independent system components. These components modularize system functionality and encapsulate their business logic that is presented as Services to be consumed by client applications or other services.
The key to these Services is their loosely coupled nature; i.e., the service interface is independent of the implementation and developers can build applications by composing one or more services without knowing the services' underlying implementations. The use of messaging to connect distributed Service components provides a consistent communication platform to ensure a scalable, decoupled and reliable system that can grow over time with minimal impact on an existing system.
This talk will demonstrate one approach to implementing just such a system; focusing on a Ruby implementation of Service functionality and a lightweight RPC framework based on the Apache Thrift protocol specification and AMQP for messaging transport.
We’ll show just how easy it can be to build such a complex and highly distributed SOA system using Ruby and a couple of other open source projects.
Rumor has it that you can't write concurrent programs in Ruby. People once believed that the world was flat and we all know how that turned out. Between the native threads introduced in MRI 1.9 and the JVM threading available to JRuby, Ruby is now a valid platform for concurrent applications. What we've been missing--until now--are the advanced concurrency tools available to other languages like Clojure, Scala, Erlang, and Go. In this session we'll talk about the specific challenges faced when writing concurrent applications; we'll explore modern concurrency techniques such as agents, futures, promises, reactors, and supervisors; and we'll use various open source tools to craft safe, reliable, and efficient concurrent code. We'll write most of our code using the Concurrent Ruby gem but we'll also explore EventMachine and Celluloid.
Neural networks are an excellent way of mapping past observations to a functional model. Many researchers have been able to build tools to recognize handwriting, or even jaundice detection.
While Neural Networks are powerful they still are somewhat of a mystery to many. This talk aims to explain neural networks in a test driven way. We'll write tests first and go through how to build a neural network to determine what language a sentence is.
By the end of this talk you'll know how to build neural networks with tests!
They say a picture is worth a thousand words. Does that mean a diagram is worth a thousand lines of code? Maybe.
Most Rubyists don't bother with drawing diagrams. We've found that our code is so expressive, that the need to explain the code in high level diagrams is greatly reduced. But greatly reduced doesn't mean never. There are times when a well drawn diagram can help us visualize the global properties of a program that are hard to see when looking at the individual source files.
Since Rubyists don't draw diagrams, we aren't aware of the rich meaning that a good diagram can convey. In this where we learn that UML is not a four letter word, but is just another tool in a well rounded developer's tool chest. Diagrams are not about big design up front, but about conveying meaning to other developers. Come join us and learn to see the big picture.
Consensus. It's not anything new. In fact, there have been great papers and discussions on the topic since the late 80's. But this year, a new consensus algorithm was written up in a paper titled, "In Search of an Understandable Consensus Algorithm". This is actually pretty rare in academia -- a paper, about a complex topic, that takes a systems approach to describing an algorithm. Not only do they give you a cheat-sheet on what RPC calls you'll need, but the entire algorithm is focused on being understandable first, which is something I think a lot of rubyists can appreciate.
I've always thought one of the major themes in the community was to focus on making software fun. Not only telling whimsical stories about foxes who like bacon or naming gems named after 90's cartoon characters, but making an effort to break problems down into small, digestible pieces and delivering them in the most practical way possible. Describing the Raft algorithm is a chance to get rubyists excited about what's going on in the distributed computing world and academia in general.
So what all do I want to teach everyone? The core concepts behind consensus, the three parts that make up the raft algorithm (consensus, state machine, and replicated log) with a toy implementation in ruby, and, most importantly, where to apply it in the real world (replacing redis, distributed configuration, and database failover). But I also have an ulterior motive, to use this unique paper to bridge the gap between academia and ruby, both making understandability more important in the education community and bringing more interesting complex projects to ruby.
Let's control physical devices using mruby on your board!
mruby has not been released yet, but you don't have to wait for it.
Current mruby is good enough for prototyping or learing.
If you have cheap microcontroller boards like STM32F4Discovery or Raspberry Pi,
you can run mruby on them and control physical devices, without other computers
to control them. And if you have right mrbgems, what you need is writing
small Ruby code, neither C nor assembler.
In this session, we will talk about how to use mruby and how to create
and use mrbgems so as to controll LEDs, buttons, accelerometer and so on.
Metaprogramming in Ruby is a mixed blessing: it makes many impossible things possible. This quicker, easier, more seductive path, however, can lead to contorted code that's difficult to maintain and can be hard to understand. So what's the alternative? For many uses of metaprogramming, good object-orientation, or a well-chosen design pattern, can provide just as much power without the challenges to intelligibility. This talk aims to (re)introduce several key Object Orientation concepts, and a few critical design patterns, then present them as superior alternatives to metaprogrammatic approaches.
In this talk we’ll dive into Ruby internals and take a close look at an ugly topic: garbage collection. How do these Ruby VM’s allocate memory for new objects? How do they identify unused objects? How do they reclaim memory from garbage objects, allowing it to be used again?
You can learn a lot about someone from their garbage. Using a series of diagrams, we’ll visually compare and contrast the complex algorithms these very different Ruby implementations use. What computer science research is behind each garbage collector? We’ll also look at the GC changes planned for the upcoming Ruby 2.1 release.
Ruby 2.1 is coming out soon with an amazing new feature under ObjectSpace: #trace_object_allocations. We are now able to trace the file and line number (as well as method) where any Ruby object is allocated from. This is a very welcome feature, as object-level tracing has been very difficult in Ruby, especially since the memprof gem could not support Ruby past 1.8.x.
This new Ruby 2.1 feature is really just exposing some raw (and vast) data, so it can be difficult to tease out meaningful information. Two gems are introduced in this talk to solve just that problem. The objspace-stats gem allows us to view and summarize new object allocations in meaningful ways. We'll look at how to filter, group, and sort new object allocations. The second gem is rack-objspace-stats. We'll see how this tool can intercept requests to a Rack stack, and measure new object allocations taking place during the request. (For those familiar, this works very similar to the rack-perftools_profiler gem.)
We'll look at various examples of how this new Ruby 2.1 feature, and these tools can help an organization reduce unnecessary memory allocations, and speed up their code, especially mature Rack applications.
The robotics revolution has already begun. You can buy drones and robotic devices at local retail stores. Unfortunately, it’s hard to develop code for robots, and nearly impossible to create solutions that integrate multiple different kind of devices.
Introducing Artoo (http://artoo.io), a new robotics framework written in Ruby. Artoo can communicate with many different kinds of hardware devices, and integrate them together. With surprisingly few lines of code, you can write interesting applications that tie together Arduinos, ARDrones, Spheros, and more... even all at the same time!
Artoo is based on Celluloid, giving it the ability to support the levels of concurrency that are required for industrial-strength robotic applications. Artoo has a built in API-server, debugging console, and even shows you how to do Test-Driven Robotics (TDR).
The time has come for Ruby-based robotics, and Artoo can help lead the way!
With Ruby you have simple tools at your fingertips that make building powerful tools easy. Ruby's standard library comes with some helpful libraries like 'delegate' and 'forwardable' that will help make your code easier to maintain.
We'll dive into how SimpleDelegator is different from method_missing and how Forwardable differs still. Learn the basis of the ideas behind these and combine the features to build your own powerful patterns. See how these compare to libraries like ActiveSupport::Delegation and look at how popular presenter libraries like Draper and DisplayCase work.
How Ruby is your Ruby? As we've found our way to Ruby, we've all brought with us habits and idioms from the languages we know and love (or hate). Sometimes, these habits serve us well, and other times, they make our lives more difficult. More often, they make life difficult for our collaborators, who don't expect to see C, Java, or PHP in their Ruby codebase.
Not only that, as many new Rubyists have found their way to Ruby from Rails, they've brought along various Rails-isms, some of which aren't even a good idea in Rails-land (callbacks, anyone?), or dependencies on libraries like ActiveSupport which are overkill for their real needs.
We'll talk about some of the baggage we bring to our Ruby code, and some simple techniques that will help us leave it behind.
Have you ever wished you could re-live the fun you had as a kid playing those arcade games? Have you ever wanted to learn 2D game programming with Ruby? Now is the time! The hardware is cheap. The libraries are easy to learn. This session will cover basic game programming techniques using Ruby, as well as the hardware and software you need in order to build and run your own Ruby-powered arcade machine.
In my wildest dreams, I never thought that I would become a software developer. I thought that I wasn't smart enough, that I needed a computer science degree and to have been writing code since I was young. But, the traditional path to becoming a developer is changing. This talk will focus on alternative and untraditional paths to becoming a developer such as programs like Railsbridge, mentorship and apprentice programs. These alternative paths ultimately foster a more diverse and inclusive community, which drives economic growth and produces more innovative solutions.
The objectives of the talk are:
- to bring awareness to the educational alternatives to computer science degrees
- to encourage empathy when mentoring a beginner
- to get the audience to see a different perspective and embrace differences in the industry
from an obscure repository, have won significant victories against
During the battle, Rebel Ruby coders have managed to duplicate the
Empire's ultimate weapon, the use of the same language on both server and
client sides, but this time with a language with enough meta programming
power to make the most elegant DSLs on the planet.
their repositories, custodian of the code that can save their people and
restore freedom to Ruby Coders everywhere.
truly exciting time with many options and opportunities.
- Yoda, if he were a coder
corelib and a runtime implementation that currently passes 1716
rubyspecs w/a reachable goal of passing them all.
You might be thinking, yet another language that compiles down to
Matz once wrote:
"For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy."
As another Ruby, Opal is designed to make programmer's happy
Here's the top 8 reasons why Opal will make you, the Ruby programmer, happy
1. It's just Ruby, and a viable one
2. Greenspun's 10th Rule, Opal Edition
3. Solves things the Ruby way, making the programmer happy
4. Frameworks, we don't need no stinking frameworks (but we have some)
5. Tools you already know and love
6. Easy integration with Ruby web frameworks
7. Awesome In Browser tools
8. New possibilities
This talk will go over those 8 reasons and more. There will be live code demonstrations.
Opal, this might just be the droid you're looking for.
I stumbled into being a maintainer on a big open source project pretty much by accident; I was contributing patches a lot and didn't want to be a nuisance, so I asked for commit privileges. At first I was just expediting my own patches, but then there were all these outstanding issues, and before I knew it I was a top committer on the project.
Being a maintainer is fun, but it can also be annoying and exhausting. I'll talk about the things that I've struggled with as a maintainer and the workflow I've developed over time to keep myself sane. There will be Git tips gleaned from kernel maintainers, ideas on encouraging contributions without feeling the need to accept every patch, straight talk on avoiding burnout, and most importantly I'll try to get across the joy that comes from being instrumental in moving a useful piece of software forward.
Not an open source maintainer and have no plans to ever be one? You should still come, since everything I talk about will also help you be a better open source contributor as well!
Although "being OO" isn't an end unto itself, we can often learn a great deal about programming by taking things to the extreme. Branching, nil checks, and attributes are not very "OO" and are often the source of great complication in our code. What would our code look like if we did everything we could to avoid them?
In this talk, we'll create some odd-looking constructs and write some weird code in an attempt to understand just how useful branching, nil, and attributes really are. Do these constructs make our code easier to read and understand, or are they vestiges from our shared programming backgrounds like C, PHP, and Java?
We all know that security is hard, and that math is hard, but what happens when you put them together? Cryptography is an increasingly essential tool for building secure systems, but also a perilous minefield where any number of mistakes can lead to insecure systems.
This talk will take you step-by-step through the difficulties of building secure cryptosystems on top of Ruby's existing OpenSSL bindings and contrast that with RbNaCl, a next generation Ruby cryptography library specifically designed to be more mistake-proof and put cryptography "on Rails". Attendees will hopefully learn that the best approaches to cryptography rest in making systems simple, straightforward, and boring... in a good way.
Can you do your work anywhere? All you need is a laptop and internet, right? What if your laptop blows up? Can you work on your phone? ipad? When you reboot your computer, does it pick up where you left off?
What if your developer machine was just another machine in the cloud? Then all you need is a terminal and an internet connection. To get work done, all you do is connect remotely to your cloud machine.
What this allows you to do is:
- Pick up where you left off (using tmux and SSH)
- Work from any device that has a terminal or terminal emulator
- Make your work available from anywhere with an internet connection. (Clients like this.)
- Do only one setup (across multiple workstations). This makes replacing your machine easy.
- Use your friend's machine without compromising any security on the project
- Pair program using tmux in your normal working environment
- Use a cheap VPS on an inexpensive laptop
Software/Packages/Services I'm using to make this work:
- Database software (PostgreSQL/MongoDB)
I've been using this setup for about a year and it has made things VERY painless for me. I've paired with clients and subcontractors with it and traveled and picked up work on devices you can't normally do development on.
Ruby-core is where Ruby features are born and bugs gets squashed. Get a glimpse of what this entails and test your Ruby knowledge and intuition at the same time.
How surely can you differentiate unexpected behavior from normality? How in tune is Matz's principle of least surprise with yours? Can you distinguish bugs from features?
We will figure it out through a series of questions inspired by actual bug reports and feature requests, spiced up with a couple of trick questions. Each question is a dilemma and everyone gets to pick if they think it's a bug or a feature.
To uncover the answers, we'll have to explore unchartered territories. We'll dig deep in recursion, battle failing specs, encounter exotic Floats and other infinities, and decipher arcane C code.
Rubyists of all levels, from beginners to hardcore pros are invited in this informal challenge. Be sure to check your ego at the door, as no-one will escape unscathed; even top notch ruby-core committers don't always get right answers! Let's discover what can lie under the apparent simplicity of Ruby without forgetting to have fun.
Splitting applications is challenging for numerous reasons. One of the biggest challenge is to keep all the applications’ data in sync. We introduce Promiscuous, an open source replication framework that facilitates data replication across applications in a safe and consistent manner. Unlike traditional approaches such as Stripe’s MoSQL and LinkedIn’s Databus, which operate at the database level, Promiscuous transparently instruments the ActiveModel interface to replicate model operations by using Redis and RabbitMQ. This makes it a great solution for separation of concerns, heterogeneous database replication, and asynchronous triggers in the datacenter.
We’ll dive into the mechanics of Promiscuous and how we used it to split our monolithic application into eight small, single purpose applications. We will also show our findings in scalability, deployment, migration, unit/integration testing, and general architecture best practices laced with real world examples.
Ruby is a rich language with dark corners. Over the years, we have been exploring more and more of these corners. But taking a step back, it's now obvious to me that there is no such thing as bad Ruby code. As programmers, we have a natural tendency to focus on code syntax, concepts and tools. But maybe we are missing the point. My talk will be in two parts: First, I will present my opinion on "bad" Ruby code and in the second, Bryan Helmkamp and Bryan Liles will join me on stage to discuss their own experience and share concrete recommendations.
As programmers, change is our only constant. Whether it's innovations in our current stack or the emergence of new languages and frameworks, there is always a new technology to explore. For many of us, that is one of the reasons we were drawn to programming. There is a profound curiosity that drives us and it's that curiosity that can lead to a Polyglot lifestyle. However, just knowing multiple languages isn't enough to claim a Polyglot lifestyle, one must actually utilize their skills. A great example is using one language to explore another. Because of it's flexibility and dynamic nature, Ruby is a great fit for this role. But where to start? In this talk we are going to explore the new functional language Elixir by using Ruby to fill in the gaps. We will look at how Ruby can be used in conjunction with the primary language to handle some of the secondary tasks seamlessly. If your interested in propagating your polyglot potential, join me in embracing Polyglot lifestyle.