Category Archives: Rails

Stop hiding the error and start fixing the problem

I’ve been working on Plataformatec for 5 years and one common mistake that I see developers making is hiding the error, instead of fixing the problem. This kind of behaviour can turn your product full of problems quickly by having a codebase with unnecessary defensive programming. Let’s explore that by taking a look at an … »

Read more at the source

Rails console shortcuts

I always forget all those handy hints in Ruby on Rails, while using my Rails console. Here I will drop some very useful console commands to get some daily jobs done: Hint No.1 Sometimes we change the code in a file. In that case we can reload the changes in the rails console by using […]

Read more at the source

[ActiveRecord] Get a polymorphic owner class out of the owned object

The question is: how can we retrieve a owners class of a polymorphic association without loading the owner object into memory? Solution There are (at least) two ways to do this. First one is not recommended (as it might fail with multiple namespaces with same class names, etc: or a better one that will work […]

Read more at the source

Trailblazer + Devise: Integrating Devise validatable model with Trailblazer operation + error propagation

Devise is one of those gems that are tightly bound to the Rails stack. It means that as long as you follow the “Rails way” and you do things the recommended way, you should not have any problems. However, Trailblazer is not the recommended way and the way it works, not always makes it painless […]

Read more at the source

Rails scaffold data types

If you work with a scaffold it can happen to anybody to forget the datatypes. Here is a cheat sheet for all the Rails 4 (ActiveRecord migration) datatypes at a glance: 12345678910111213 :binary :boolean :date :datetime :decimal :float :integer :primary_key […]

Read more at the source

Keeping your Ruby on Rails app easy to update

The Rails 5 release candidate is out, bringing new improvements that will make your life as a developer easier. Probably you are excited to update your application to the new major Rails release, but you may have some concerns. It is normal, updating your application to fit the new version may bring an unknown number … »

Read more at the source

Errbit + HTTPS: Setting up Errbit reporter (Airbrake v5 gem) to work with self-signed HTTPS certificate

Note: If you’re using old Errbit version (0.2.0, 0.4.0) and an old Airbrake version (v4) please refer to this manual to make it work with self-signed certificates. Having an error catcher like Errbit behind SSL is generally a good idea. Especially when Errbit is hosted on a different server than you application (for example when […]

Read more at the source

Integrating Trailblazer and ActiveRecord transactions outside of a request lifecycle

When you use Ruby on Rails with ActiveRecord, you can get used to having separate transaction on each request. This is valid also when using Trailblazer (when inside of a request scope), however Trailblazer on its own does not provide such functionality. It means that when you’re using it from the console and/or when you […]

Read more at the source

Rails + Responders + Trailblazer – Flash messages with proper model names from Trailblazer operations

Responders gem is really awesome. It sets flash message based on the controller action and resource status allowing you to dry up your Rails controllers. Trailblazer is a thin layer on top of Rails. It gently enforces encapsulation, an intuitive code structure and gives you an object-oriented architecture. When combining both of them together, you […]

Read more at the source

Upgrading to Ruby on Rails 5.0 from Rails 4.2 – application use case

In this article, I’ll try to cover all the issues that I had, when I was upgrading one of my Rails app from Ruby on Rails 4.2 to Ruby on Rails 5.0. Note: This is not a complete, covering every possible case tutorial. You might encounter issues that I didn’t. If so, feel free to […]

Read more at the source

Adding Twitter’s Bootstrap CSS to your Rails app

November 10, 2011

Bootstrap in action, as demoed in Luca Pette's article

Updated Feb 2012 for Bootstrap 2.

Twitter’s new CSS toolkit, Bootstrap, is all the rage these days. I explain how to get the CSS, and optionally the mixins and the JavaScript, into your Rails app.

“How do I serve Bootstrap through Rails 3.1’s asset pipeline?”

Just add Ken Collins’s (@metaskill’s) less-rails-bootstrap gem (announced recently on his blog) to your Gemfile:

1	`gem 'less-rails-bootstrap'`

Require it in your app/assets/stylesheets/application.css:

1	`*= require twitter/bootstrap`

Done. You now have Bootstrap 2 working in your Rails app. :-)

By the way: Did you know that Bootstrap is written in LESS, a stylesheet language like SCSS?

“Ugh, I hate LESS. Can I get Bootstrap as plain CSS please?”

That’s OK, not everybody likes LESS. Behind the scenes, less-rails-bootstrap transparently compiles the Bootstrap LESS files into CSS through Rails’s asset pipeline (using the less-rails gem). This means that there is no scary client-side compilation with less.js (like the LESS website advertises). And on the Rails side, you can just carry on using SCSS. In other words, Bootstrap by default acts like any regular CSS library – all the LESS stuff is hidden from you.

“I love LESS. Can I use the Bootstrap mixins in my LESS code?”

Sure you can. Just import the mixins and variables in any stylesheet file ending in .less (like posts.css.less):

@import "twitter/bootstrap/variables";
@import "twitter/bootstrap/mixins";

div.post {
   color: @yellow;  // <-- using variables
   #gradient.vertical(@black, @blue);  // <-- using mixins
}

Warning: Do not get confused about requiring vs importing:

Use = require twitter/bootstrap at least once (typically in application.css) to get all the CSS rules that come with Bootstrap. The files will be processed through Sprockets (Rails’s asset handler), which guards against duplicate inclusion. If you tried to require the mixins or variables, it would have no effect, since Sprockets compiles them separately from your stylesheets.
Add the two @import lines above to every LESS file in which you want to use Bootstrap mixins or variables. As you can verify by inspecting the CSS output, importing them has no effect (i.e. no CSS rules are generated) until you actually use the mixins and variables in your own CSS rules. If you tried to @import the entire “twitter/bootstrap” library, it would show up multiple times in your compiled CSS assets, because Sprockets can’t guard against duplicate inclusion when you use @import.

To summarize, require the entire toolkit, and @import the mixins and variables.

“Can I use Bootstrap’s JavaScript plugins?”

Easy enough. Add this to your application.js:

1	`//= require twitter/bootstrap`

The plugins load through jQuery’s .ready, so be sure to wrap your own code as well:

1
2
3

$(function() {
  // ...
});

“Now how do I get started using Bootstrap in my layouts and views?”

Try adding a button in any view file – it should be rendered pretty:

1	`<input type="button" value="Click me" class="btn primary">`

Or try adding a black navigation bar to your layout:

<div class="navbar navbar-fixed-top">
  <div class="navbar-inner">
    <div class="container">
      <a class="brand" href="/">Whizboo App</a>
      <ul class="nav">
        <li class="active"><a href="/">Home</a></li>
        <li><a href="/about">About</a></li>
      </ul>
      <ul class="nav pull-right">
        <li><a href="/sign_in">Sign In</a></li>
      </ul>
    </div>
  </div>
</div>

Fore more inspiration, check out Luca’s article about using Bootstrap with Rails.

“I want more explanation. / I heard there is a Sass version of Bootstrap.”

Check out ”Twitter Bootstrap, Less, and Sass: Understanding Your Options for Rails 3.1” on RubySource!

[…]

5 Reasons to Use Protocol Buffers Instead of JSON For Your Next Service

June 5, 2014

Service-Oriented Architecture has a well-deserved reputation amongst Ruby and Rails developers as a solid approach to easing painful growth by extracting concerns from large applications. These new, smaller services typically still use Rails or Sinatra, and use JSON to communicate over HTTP. Though JSON has many obvious advantages as a data interchange format - it is human readable, well understood, and typically performs well - it also has its issues.

Where browsers and JavaScript are not consuming the data directly – particularly in the case of internal services – it’s my opinion that structured formats, such as Google’s Protocol Buffers, are a better choice than JSON for encoding data. If you’ve never seen Protocol Buffers before, you can check out some more information here, but don’t worry - I’ll give you a brief introduction to using them in Ruby before listing the reasons why you should consider choosing Protocol Buffers over JSON for your next service.

A Brief Introduction to Protocol Buffers

First of all, what are Protocol Buffers? The docs say:

“Protocol Buffers are a way of encoding structured data in an efficient yet extensible format.”

Google developed Protocol Buffers for use in their internal services. It is a binary encoding format that allows you to specify a schema for your data using a specification language, like so:

message Person {
  required int32 id = 1;
  required string name = 2;
  optional string email = 3;
}

You can package messages within namespaces or declare them at the top level as above. The snippet defines the schema for a Person data type that has three fields: id, name, and email. In addition to naming a field, you can provide a type that will determine how the data is encoded and sent over the wire - above we see an int32 type and a string type. Keywords for validation and structure are also provided (required and optional above), and fields are numbered, which aids in backward compatibility, which I’ll cover in more detail below.

The Protocol Buffers specification is implemented in various languages: Java, C, Go, etc. are all supported, and most modern languages have an implementation if you look around. Ruby is no exception and there are a few different Gems that can be used to encode and decode data using Protocol Buffers. What this means is that one spec can be used to transfer data between systems regardless of their implementation language.

For example, installing the ruby-protocol-buffers Ruby Gem installs a binary called ruby-protoc that can be used in combination with the main Protocol Buffers library (brew install protobuf on OSX) to automatically generate stub class files that are used to encode and decode your data for you. Running the binary against the proto file above yields the following Ruby class:

#!/usr/bin/env ruby
# Generated by the protocol buffer compiler. DO NOT EDIT!
require 'protocol_buffers'

# forward declarations
class Person < ::ProtocolBuffers::Message; end
    
class Person < ::ProtocolBuffers::Message
  set_fully_qualified_name "Person"
      
  required :int32, :id, 1
  required :string, :name, 2
  optional :string, :email, 3
end

As you can see, by providing a schema, we now automatically get a class that can be used to encode and decode messages into Protocol Buffer format (inspect the code of the ProtocolBuffers::Message base class in the Gem for more details). Now that we’ve seen a bit of an overview, let’s dive in to the specifics a bit more as I try to convince you to consider taking a look at Protocol Buffers - here are five reasons to start.

Reason #1: Schemas Are Awesome

There is a certain painful irony to the fact that we carefully craft our data models inside our databases, maintain layers of code to keep these data models in check, and then allow all of that forethought to fly out the window when we want to send that data over the wire to another service. All too often we rely on inconsistent code at the boundaries between our systems that don’t enforce the structural components of our data that are so important. Encoding the semantics of your business objects once, in proto format, is enough to help ensure that the signal doesn’t get lost between applications, and that the boundaries you create enforce your business rules.

Reason #2: Backward Compatibility For Free

Numbered fields in proto definitions obviate the need for version checks which is one of the explicitly stated motivations for the design and implementation of Protocol Buffers. As the developer documentation states, the protocol was designed in part to avoid “ugly code” like this for checking protocol versions:

if (version == 3) {
  ...
} else if (version > 4) {
  if (version == 5) {
    ...
  }
  ...
}

With numbered fields, you never have to change the behavior of code going forward to maintain backward compatibility with older versions. As the documentation states, once Protocol Buffers were introduced:

“New fields could be easily introduced, and intermediate servers that didn’t need to inspect the data could simply parse it and pass through the data without needing to know about all the fields.”

Having deployed multiple JSON services that have suffered from problems relating to evolving schemas and backward compatibility, I am now a big believer in how numbered fields can prevent errors and make rolling out new features and services simpler.

Reason #3: Less Boilerplate Code

In addition to explicit version checks and the lack of backward compatibility, JSON endpoints in HTTP based services typically rely on hand-written ad-hoc boilerplate code to handle the encoding and decoding of Ruby objects to and from JSON. Parser and Presenter classes often contain hidden business logic and expose the fragile nature of hand parsing each new data type when a stub class as generated by Protocol Buffers (that you generally never have to touch) can provide much of the same functionality without all of the headaches. As your schema evolves so too will your proto generated classes (once you regenerate them, admittedly), leaving more room for you to focus on the challenges of keeping your application going and building your product.

Reason #4: Validations and Extensibility

The required, optional, and repeated keywords in Protocol Buffers definitions are extremely powerful. They allow you to encode, at the schema level, the shape of your data structure, and the implementation details of how classes work in each language are handled for you. The Ruby protocol_buffers library will raise exceptions, for example, if you try to encode an object instance which does not have the required fields filled in. You can also always change a field from being required to being optional or vice-versa by simply rolling to a new numbered field for that value. Having this kind of flexibility encoded into the semantics of the serialization format is incredibly powerful.

Since you can also embed proto definitions inside others, you can also have generic Request and Response structures which allow for the transport of other data structures over the wire, creating an opportunity for truly flexible and safe data transfer between services. Database systems like Riak use protocol buffers to great effect - I recommend checking out their interface for some inspiration.

Reason #5: Easy Language Interoperability

Because Protocol Buffers are implemented in a variety of languages, they make interoperability between polyglot applications in your architecture that much simpler. If you’re introducing a new service with one in Java or Go, or even communicating with a backend written in Node, or Clojure, or Scala, you simply have to hand the proto file to the code generator written in the target language and you have some nice guarantees about the safety and interoperability between those architectures. The finer points of platform specific data types should be handled for you in the target language implementation, and you can get back to focusing on the hard parts of your problem instead of matching up fields and data types in your ad hoc JSON encoding and decoding schemes.

When Is JSON A Better Fit?

There do remain times when JSON is a better fit than something like Protocol Buffers, including situations where:

You need or want data to be human readable
Data from the service is directly consumed by a web browser
Your server side application is written in JavaScript
You aren’t prepared to tie the data model to a schema
You don’t have the bandwidth to add another tool to your arsenal
The operational burden of running a different kind of network service is too great

And probably lots more. In the end, as always, it’s very important to keep tradeoffs in mind and blindly choosing one technology over another won’t get you anywhere.

Conclusion

Protocol Buffers offer several compelling advantages over JSON for sending data over the wire between internal services. While not a wholesale replacement for JSON, especially for services which are directly consumed by a web browser, Protocol Buffers offers very real advantages not only in the ways outlined above, but also typically in terms of speed of encoding and decoding, size of the data on the wire, and more.

What are some services you could extract from your monolithic application now? Would you choose JSON or Protocol Buffers if you had to do it today? We’d love to hear more about your experiences with either protocol in the comments below - let’s get discussing!

[…]

The Ruby Rails Aggregator