As software systems become more complex, Service-Oriented or Microservice architectures become common. While these architectures have their benefits, they make building and testing your Rails application more complicated because of runtime dependencies. Chris shares his experiences building Rails applications in an SOA that keeps Rails development awesome.
Developers are concerned about concerns. When used correctly and in moderation, ActiveSupport::Concern is a useful tool. It improves code clarity, keeps it DRY, and encapsulates shared logic. In this talk, I'll explain what happens when ActiveSupport::Concern is included in Rails models and controllers, and how it differs from a plain old module. We'll walk through some example code, discuss best practices, and test them with RSpec. It's not all roses though. To close, we'll examine the drawbacks and explore alternatives.
Docker is a platform for packaging applications to be run in multiple environments. Docker containers operate like lightweight VMs that share a common kernel. They are easy to manage, start in less than a second, and are a breeze to share with others using the Docker index. We’ll see how to “dockerize" a Rails application and some fun ways we can use other Docker containers from within Rails.
Recently, you may have watched a talk during which the speaker said:
"A lot of people will gripe about 'ActiveRecord is too big, [...] has too many methods, the surface area is too big.'"
Hi, my name is "A. Lotofpeople", and I'd like to discuss with you why I've been griping.
We'll talk about what "clarity" means to Rubyists, and its relationship to the hard problem of naming things. I'll share some principles that I've found helpful, coping mechanisms I've developed to allow me to "fight the framework" without suffering too badly, and thoughts on what some first steps toward bringing clarity to a Rails codebase might look like.
Or, I might just talk about cats. You'll have to attend to find out!
Sometimes you get to start fresh, with the latest version of ruby, the latest web server, the latest database, and your choice of dependencies. But sometimes, you have to work with an old codebase. This codebase might have been started years ago, by tens or hundreds of people, many of whom no longer work for the organization. This talk is the story of one such codebase, and how to work with it every day.
Ever wondered what "C extension" are about and what value they hold for us as Rubyists? Curious about what's involved in putting one together? You're in luck! This talk will walk you through the concepts behind Ruby C extensions, why they're useful and how to go about writing them. You'll also walk away with some worthwhile resources for further exploration.
We follow best practices like test driven development with the hope of minimizing bugs and making our applications easier to work with over time. These techniques will take us far, but why should we limit our efforts to just the code we write? In this talk we will explore how the history of a codebase affects the live's of the developers working on it. We will dig into manipulating a codebase to create an effective history through writing wonderful commit messages, creating topic branches and rebasing commits. Let's explore how we can make life a bit more manageable in the fast moving world of software development.
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).
People don't typically think of Ruby when it comes to embedded Linux development boards like Raspberry Pi and BeagleBone, but it is indeed possible to run the full Rails stack on such systems and use that micro server to interact with the physical world.
In this talk I'll show how Rails and Raspberry Pi are being used to create a simple interface for a Burning Man art project. I'll cover the pieces I used to get rails running on Pi, contributions to the pi_piper gem, software design decisions, hardware design and interaction, issues, and possibilities for improvement.
Many of us have crossed the rubicon and tackled the tricky (and sinister) issue of handling timezones in our code. For those of you who haven't, or to varying degrees, this talk is for you. Why is this an issue? What tools are available to us? In my talk I'll share the challenges I've run into and share some code that makes it a little easier.
Refactoring is an important part of maintaining a large codebase. However, for many developers, deciding when and what to refactor can be stressful. As an individual or team, its easy to fall into a trap of refactoring too little, which can result in large amounts of technical debt or a trap of refactoring too much, which slows forward progress. In this talk, we'll explore a framework for determining when, what, and how much to refactor a growing Rails codebase. Examples will be provided for each concept and you'll walk away with a number of questions to ask yourself and your team along with a number of Rails-specific tricks and techniques.
As your application grows in complexity, breaking it up into independent components that communicate over a stable API contract can reduce that complexity into smaller maintainable concerns. Instead of deploying multiple Rails applications, there are leaner alternatives in the Ruby ecosystem such as Middleman and Grape. We'll take a look at these tools and strategies for managing configuration and compatibility between different components of a service-oriented-architecture (SOA). Additionally, we'll cover exactly when SOA is beneficial and how to determine if you should switch to it.
Rubyists generally tend to shy away from multi-threaded code.
Cognitive overload, horror stories of threading bugs, and MRI's lack of native threading support are probably the reasons, but these are powerful constructs that every developer should understand. We'll tour the basic synchronization primitives that Ruby provides, and I'll show you where each is appropriate, covering potential pitfalls and hazards along the way. We'll see the strengths and limitations of the way MRI, Rubinius, and JRuby run our multithreaded code, and the implications that that has on our code's progress.
Devise is pretty widly used, but have you ever needed more out of it? With the recent release of 3.1.0, Token Authenticatable has been dropped; how can you replace it securely? This talk will quickly go over the basics of Devise, dive into its core use of Warden and we'll write a few new custom strategies. Developers walking into the talk without any previous exposure to Devise will get a quick intro, casual users will get a better understanding of how its innards work, and the seasoned will get to see how one group addressed api authentication token generation while avoiding the timing security issues that had previously existed.
Does the code you write have a bright future? Or is it destined to rot and turn brains to mush? Find out how to keep your code from getting infected with the zombie virus of entropy and kept fresh and alive using insights from cognitive psychology.
In this talk we'll introduce InfluxDB, a distributed time series database we open sourced based on our backend infrastructure at Errplane. I'll talk about why you'd want a database specifically for time series and cover the API and some of the key features of InfluxDB
With 14 months and 6 workshops down, RailsBridge Boston has taught Ruby and Rails to over 200 women. What's making these workshops so successful? Why do people keep coming!? All sources point to our TAs. In this talk, we'll take a look at what they're doing and how we can do the same to better foster our community.
Are you new to the world of software development, trying to find a way to break in? Are you an experienced developer from the .NET or Java world trying to find a way to break out? Two years ago, I was in a management role with a medical device company, moving slowly away from something I love, writing software. My experience was heavy on the embedded and desktop side, primarily in C#, with little web experience. I loved TDD and agile, but didn't find much love for XP practices in those communities. I had heard a lot about how these ideas were valued in the Ruby community but how was I going to break in. This talk will go into some of the things I did to gain a toehold. Along the way, we'll talk about fear, imposter syndrome, leveling up your skills, and getting involved in the community. We'll also talk about some of the roadblocks you will face and some unspoken, and not so unspoken, negative aspects of the industry.