Your monolithic application is getting unwieldy. Concerns are entangled, response time is getting sluggish, and changing anything in production requires deploying your entire system. Teams facing this challenge often have an "Introduce Services" chore in their backlog that inevitably sinks to the bottom of the list. Despite the realization that your monolithic application will sink under its own weight, you fear the inherent operational complexities of a service oriented system.
The complexity of operating services results from the reality that your system will be only as strong as the weakest dependent service. Synchronous service requests require a round-trip request and response cycle in real-time. Your system's response time now might be only as fast as your slowest service and its uptime might be only as high as your weakest service. This potential brittleness is a high barrier to entry.
The boundaries of our potential services are defined by their communication patterns. One path forward toward service oriented design is to first target the components of your system that communicate asynchronously. These interactions do not require a roundtrip response in real-time and instead rely on incoming messages. First focusing on services that can be addressed through delayed messages will allow us to begin to carve up our application while ensuring the operational integrity of our system.
In this talk we'll look at using message passing patterns when designing our service oriented systems. We'll dig into an evolving feature from being some code sprinkled throughout the app folder in our Rails application to a standalone system that's independently scalable, testable, and deployable. We'll investigate the tactics we use to slice up our monolithic application, the operations and monitoring concerns it introduces, and look at several different messaging tools and protocols along the way.
It started as an obsession with making the web application used at my day job faster, and ended with trying to implement new Garbage Collection algorithms in a notoriously insane codebase. Garbage collection is an epic hack and a triumphant abstraction that supports various programming paradigms. As hardware and software changes, Garbage Collection's role also changes but remains equally important. I'll discuss my experiments with MRI Ruby, my investigations into other languages and the influence of their GC implementations, the history of the subject, and more.
Cheap code branches permeate our daily workflow, but the code we write is only half the story. Introducing data model changes into production can challenge developers and ops people alike, but how do we deal with these issues in our experimental phase?
In this talk, we'll discuss using features provided by modern filesystems like ZFS & Btrfs to branch databases along with code, letting developers experiment and ops people model complex environments, all from the comfort of our laptops.
In the past year or so, RubyMotion (RM) has gained its share of both adherents and skeptics. Some criticize RM for being too far removed from the underlying Cocoa frameworks, while others claim the toolchain isn’t "Ruby" enough. While there is certainly merit to these conflicting objections, it is because of these supposed flaws, and not in spite of them, that RubyMotion is an excellent tool for producing iOS apps. By leveraging both the power of the Objective-C frameworks and the speed and expressiveness of Ruby (not to mention opening up the iOS ecosystem to the historically prolific open source Ruby community), RM has the potential to greatly expand the iOS developer base and change the mobile landscape for the better. In his talk, "Motion in the Middle," Matthew will discuss the ways in which RubyMotion enables elegant, Ruby-esque design while exposing enough of the iOS/Cocoa frameworks to allow for wide-ranging and highly extendable applications.
When I was asked to teach Ruby on Rails at Columbia University I observed that a significant number of the skills required to become a successful professional in the industry are acquired on the job and aren’t being taught in school. Many of us professionals thrive on open source software and on sharing code, but academia is not always teaching this type of resourcefulness to students.
This presentation will cover lessons learned from the experience teaching in my alma mater's CS program, how I developed a hacker-centric curriculum, and how we as hackers can fix this.
Welcome to the trials and tribulations of managing a Ruby team. Let me introduce you to the characters, the challenges, the high stakes rat race. I'll share as fast as possible, what I've learned and what I failed at and why management shouldnt be an evil word.
In Rails, we have a beautiful framework that can take us from a blank slate to a fully-functional app in little time. However, doing things "The Rails Way" has a lot of implicit dependencies, including persistence. Are you really equipped to make one of the largest decisions about your app before any of your code has even been written?
By putting this decision off you can get a feel for your domain before ever committing anything to a db schema. This means fewer migrations and fewer db-related hacks. Also, these practices encourage encapsulation and interchangeability, which means you get the ability to choose which datastore is best for you. Not just on an application level, but on a per model level as well!
During the talk we’ll be walking through simple examples at different points in application lifecycle. These snapshots will address the biggest pain points of a persistence free process and leave you in a position to put off persistence in your own app development!
Many people don't like Cryptography. Whenever he falls out of a bar, he carries this strong odor of ivory-towering, bikeshedding and plain, outright arrogance. He seems to be a loner and a smartass, rude, and it's hard to follow his boring, lengthy explanations. But once you get to know him better, it actually turns out that he's really a nice guy. Sure, a little bit paranoid, but his intentions are pure and just. He'll probably never be your buddy on Facebook ('cause he likely won't set up an account in the first place), but over time you will realize that it can be quite pleasant having him around.
Krypt is the tool that tames him, and krypt is the tool that translates his sentences into plain, understandable Ruby. Gone are the times when you just couldn't figure out what parameters to use in order to please him, gone are the times when he would take your passwords and not stow them away safely because yet again he didn't fully understand what you were asking him to do. OK, this metaphor thing is getting a little old now. krypt makes using crypto fun and easy, and it works on all Rubies on all platforms (yep, Windows, too) - out of the box, no restrictions. It is about diversity - it allows you to choose from different providers that are best-suited for the particular task at hand.
You'll get a whirlwind tour of how krypt is different than other crypto libraries and why. You'll find out about the finer pieces of its inner workings and you might take home a few tricks that evolved while developing the native extensions that sit at the very heart of krypt. With its recent integration into JRuby, you might already be using krypt with JRuby right now without even knowing. Learn about the details and how krypt is used to simulate OpenSSL features that were not available in JRuby before. Find out more about how it can help making Ruby a safer place. krypt tries to ultimately replace the OpenSSL extension in the Ruby standard library, and with our combined effort we could actually steer the story of Ruby cryptography towards a happy ending.
Find out how!
The story of the quest to make bundle install faster; in which Rubyists around the world inadvertently DDoS rubygems.org, witness its ignominious death, and vow to rebuild it from the ashes stronger than it was before. Then, a tour of the changes; why is Redis so much slower than Postgres? Marvel at the gorgeous metrics and graphs used to measure and optimize; gasp in delight as we track, live, exactly how many Heroku dynos are needed. Finally, a happy ending: today, the server responds to requests TWO ORDERS OF MAGNITUDE faster than it did before.
In this talk we will go over usability heuristics for building better web experiences.
This talk will explore the design and architecture of the VHX theme engine, which allows our filmmakers to easily create highly-customizable websites to promote and sell their movies. We’ll walk through the technical and UX decisions that were made to optimize for maintainability, flexibility and future-proofing.
We’ll show off the code involved in VHX’s theme engine, advanced code editor (with live previewing through the HTML5 postMessage API), a master/child inheritance system that allows themes to be forked, and piecing it all together in a beautiful, easy-to-use interface.
With RoR, often the focus is on how easy it is to build an application from the ground up. But, there is a whole different set of challenges when working on a mature application.
This talk will discuss the issues discovered when peeling back the layers of a 7-year-old pile of code. In the beginning, the question isn’t “How do I build this,” but more like “Where does this go” or “Where is this bug coming from.” I will discuss the sometimes-unintended consequences of introducing new features, tracking down and fixing ancient bugs, estimating the time a new feature will take to build given the many other peculiar surprises you will uncover, and finally how not to worry about the inevitable day when you will break everything.
The audience will hear from a developer who works with old code every day and get tips to make their future selves and successors less confused, more productive, and less unintentionally destructive.
Over the past few years, Nokogiri has slowly eclipsed older XML parsing libraries to garner nearly 10 million downloads from rubygems.org.
But why another XML parsing library? Isn't it boring? And what does "nokogiri" mean in Japanese, anyway?
These questions will be answered, and I'll do a brief dive into all the technologies that we use to make Nokogiri a fast, reliable and robust gem. Topics will include:
Origins of the project: motivation, problems and impact
Native C and Java extensions
FFI, and how to know if it's Right For You
Debugging tools (valgrind, perftools)
Packaging tools (mini_portile, rake-compiler)
Installation issues, and what we're doing to help
While Ruby is object oriented and imperative, it does have some features that allow for functional programming. In this talk we’ll compare Haskell, a functional programming language, with Ruby while exploring these common functional patterns: higher order functions, lazy evaluation, and memoization.
Along the way we’ll explore how Ruby works internally, find out whether it’s a true functional language, and zoom in to take a close look at Ruby 2.0’s implementation of the new “Enumerator::Lazy” feature.