bgror

Instrumenting excon »

Created at: 01.03.2012 21:57, source: Engine Yard Blog, tagged: ruby Technology

At Engine Yard we make heavy use of fog to interface with back-end cloud providers. Fog in turn uses excon to make HTTP requests. A few features make excon a better choice than Net::HTTP:

• Better at reusing connections.
• Automatic retries for idempotent requests.
• Easy to stub for your unit tests.

My coworkers and I at Engine Yard needed to measure the performance of fog’s HTTP calls so we added one more feature to excon: instrumentation.

Enter ActiveSupport::Notifications

Larry Diehl called my attention to the new-fangled notification API in Rails 3, namely, ActiveSupport::Notifications. Rather than reinvent the wheel, said Larry, it made sense to use an existing API which at least some people would already be familiar with. ActiveSupport::Notifications is an implementation of our old friend, the publish-subscribe pattern and turns out to be pretty easy to use.

I won’t re-create the RDoc here, but the basic idea is you can instrument blocks of code by wrapping them in an #instrument call like so:

ActiveSupport::Notifications.instrument("cheezburger", :extra => :information) do
  # Do stuff.
end

Elsewhere in your app you can record those events by subscribing to them:

ActiveSupport::Notifications.subscribe(/cheezburger/) do |*args|
   puts "K THX BAI"
end

Now every time the first block is called, we’ll be notified with a call to the second block. Excellent. Now what?

With excon

When you include an instrumentor class in the Excon constructor you can then subscribe to excon’s events:

connection = Excon.new('http://icanhascheezburger.com/',
    :instrumentor => ActiveSupport::Notifications,
    :instrumentor_name => 'myapp.excon')

# Elsewhere...
ActiveSupport::Notifications.subscribe(/myapp.excon/) do |*args|
  puts "Excon did stuff!"
end

If :instrumentor_name is omitted, the base name defaults to “excon”. Excon generates three different events: excon.request, excon.retry, and excon.error. Requests and retries each have associated durations, errors do not. By digging into args we can determine how long the request took along with other assorted goodness.

Too many gems!

Suppose you don’t want to include activesupport in your application. No problem. Simply define a class which responds to the #instrument method and record incoming events however you please.

class SimpleInstrumentor
  class << self
    attr_accessor :events

    def instrument(name, params = {}, &block)
      puts "#{name} just happened."
      yield if block_given?
    end
  end
end

connection = Excon.new('http://icanhascheezburger.com/', :instrumentor => SimpleInstrumentor)

Go forth and conquer

Hopefully I’ve given you enough information to start measuring excon for your own purposes. In a future post I’ll discuss how we used this excon feature to make pretty graphs of our fog calls to AWS.

Rails Development on Windows. Seriously. »

Created at: 29.02.2012 17:47, source: Engine Yard Blog, tagged: ruby Technology

I love Windows. I love how stupidly easy it is for browsing the web, checking email, or writing Word documents (if you actually still do that). I love that Windows is everywhere and even my grandmother can use it.

At the same time, I also HATE Windows. If you're trying to program anything besides .NET, it's an uphill battle.

The title of this post is 'Rails Development on Windows. Seriously.' I'm going to discuss the past, the present, and the future of being a Rails developer in a Windows world; and show you some of the tools you need to be successful.

The Past

Don't tell anyone because it might ruin my street-cred, but I started programming Ruby on Rails in a Windows environment. At the time (fall 2008) I was using Windows Vista.

Yes, you can all shudder in fear.

As bad as that release was, I made the most of it. Having my only programming experience in a classroom-setting, I installed Aptana RadRails and hit the ground...stumbling.

Back then, there were basically two ways to install Rails on Windows:

1. Install JRuby and run on top of the Java Virtual Machine
2. Download the RubyInstaller executable and the DevKit and install everything manually

I had no idea what JRuby really was or why I needed it and I really wasn't sure what I was doing in the first place so I opted for option two. I think there may have been a way to install through RadRails but it was a craps-shoot if it worked properly.

Everything installed fine and as long as you accepted all defaults then you were golden. Heaven help the programmer who wanted to install Ruby to a different path.

The biggest problem with having to install Ruby this way is that if you didn't grab the DevKit, you couldn't build any C extensions. By the way, Ruby is written in C and there are a wealth of libraries that require C extensions to build correctly. For beginners to run into these errors when all they want to do is write a web app, this sucked.

The Present

Let's fast-forward to 2012 and the biggest savior to Rails developers who want to use Windows is RailsInstaller, created and maintained by Wayne E. Seguin.

If you don't know Wayne, he works non-stop on Ruby Version Manager, SM Framework, and RailsInstaller. He does it all for the good of the community, so buy him a beer next time you see him.

RailsInstaller is an amazing piece of software because it packages up everything you need to start programming Ruby on Rails. Out of the box, you get Ruby, Rails, Bundler, Git, Sqlite, TinyTDS, the DevKit for those pesky C extensions, and you actually get support for SQLServer. Trying to hunt down all of these components and installing them separately is a nightmare.

The Future

Honestly, I don't know what's in store for the future right now, but it has to be better than the past. We've come a long way and there's still a lot of work to be done.

So you've installed RailsInstaller and now you have a Ruby on Rails environment but where do you go from here?

What do I need?

Here are some of the essential things you need to be a successful Rails developer in Windows

Git

If you aren't tracking your changes with Source Code Management, you need to get with the program. I don't care what anyone says, the best one is Git. The best thing about Git is that it's distributed. This means everyone has the full code repository so no waiting on the Subversion server! There's also Github and if you aren't familiar with it, it's amazing. Github brings a social aspect to coding and provides for easy collaboration.

Honestly, I don't care what SCM you use as long as you use something. Quit creating index.html.old. That isn't reliable and if you use a code-hosting service, then you don't need to worry about your computer crashing. And we're running Windows so this is something we probably worry about a few times a day.

Pik

Ruby Version Manager, or RVM, is another exceptional tool written by Wayne. It makes it easy to manage different versions of Ruby, provides sandboxed environments for different projects, and allows people to test software compatibility. Unfortunately it doesn't run on Windows.

The next best thing is a tool called Pik. Using Pik, you can install different versions of Ruby including JRuby and IronRuby. It doesn't have the bells-and-whistles that RVM does but trying to run mutliple Rubies without it would be a nightmare. You can grab Pik from the Github page.

IDE or Text Editor

Now you need a way to actually write your applications. No, we're not going to fire up Visual Studio; it doesn't tend to play well with Rails When choosing an editor, you can either go with a Text Editor or an Integrated Development Environment. All of the options I'll talk about run across platforms so you can use them on Windows, Mac, or Linux.

IDEs

If you're used to an all-in-one package, there are great offerings in JetBrains RubyMine and Aptana Studio. You have to pay for RubyMine but it is by far the most polished and has a ridiculous amount of features for editing, testing, and deploying your application.

Aptana Studio is a free option and if you don't want to shell out the money for RubyMine, is a great alternative. It's built on top of Eclipse so the Java developers will feel right at home.

Text Editors

My favorite and the option chosen by most Rails developers is just a Text Editor. There are a few different options that I recommend but the one thing I don't is Notepad.

Vim is tried and true and has been around forever. It's incredibly extensible, and very fast. People tend to say that learning Vim is hard but really there are a handful of commands to really need to know off the bat and the rest you can pick up as you go. The best thing about Vim is that you can launch it from the command line and start editing.

SublimeText is something that has a pretty big following. It costs a little bit of money and has support for Ruby and Rails baked in. I definitely encourage you to check this one out.

Redcar is a great editor that is actually written in Ruby. Because of this, extending it is easy since you can write the extensions and don't need to learn a separate syntax. Another nice thing is that Redcar has support for TextMate bundles so you can probably find extensions for anything you need.

Learn something

Rails has an incredible community. Learning how to write great Ruby on Rails applications has never been easier and there are resources for any type of learning style.

Screencasts

I have to mention Railscasts becuase the amount of knowledge is just amazing. Ryan Bates has been doing weekly screencasts on Rails topics since 2007(?). These are usually around 10-15 minutes and cover one thing each episode. If you want to learn how to add authenticationto your app quickly and easily, check out Railscasts.

Tutorials

By far, the best tutorial is RailsTutorial by Michael Hartl. He goes into detail on topics such as Ruby, Rails, and test-driven development. The HTML version of the book is free and you can also purchase the PDF. If you want even more instruction, he has some great screencasts there as well.

You can find many more tutorials, screencasts and documentation at rubyonrails.org and by searching Google.

Show the world

So you've written your first Ruby on Rails application and you're wondering where to go from here. Let's share this really cool application with the rest of the world. Save yourself a headache and a lot of work and don't think about deploying to a Windows server. Thankfully, there are multiple Cloud Platform providers these days so you don't even need to set up your own server. I'm obviously biased towards Engine Yard but there are other options and you can see which one fits you better.

Caveat

There's one major thing to know when writing Rails apps on Windows and it mainly comes into play when working across platforms. Because many Windows requires binaries many times for the gems to work correctly, gem developers will release different versions for Unix and Windows. If you're deploying to a Unix environment, you'll need to make sure to install the Unix versions wherever you're deploying.

Troubleshooting

Inevitably, you're going to run into trouble. Even with all of the documentation available, you still sould know where to go for help.

Ruby on Rails Guides

The Ruby on Rails Guides are exactly what they say. They're basically the official documentation for Rails. Often times they are a great starting point if you need reference for standard Rails topics.

Forums

If you need help on something out of the scope of the guides, a good forum is your next best place. StackOverflow is probably the widest used forum site for programming help. You can ask and answer questions and there is a point system for your activity. The questions are also indexed by Google so a well-formed Google search returns great results.

IRC

The place I go when everything else fails is IRC, which stands for Internet Relay Chat. IRC has been around for years and though I've never been a huge fan, you can talk with people in real time about your issues.

If you're going to be in IRC rooms a lot, you need to find a good desktop client. I've used mIRC with decent success but I'm sure there are many more out there. Whichever you choose, there are a couple rooms that you need to hang out in: #Rails and #RailsInstaller.

What's next

I know this seems like a lot of information up front and I could probably go into much more detail but I'm trying to save your sanity. If you want to check out the slides from my talk, you can go to emachnic.github.com/rails_dev_windows.

The best thing you can do is get the software and start building something. You can read all of the books and watch all the screencasts you want but until you build a real application, the information won't stick. If you need help, use the resources and you can find me online everywhere as emachnic. Good luck and most important, HAVE FUN!

I'd like to thank everyone on the RailsInstaller and RubyInstaller teams (Wayne E. Seguin, Luis Lavena, Ken Collins, etc.), as well as anyone who has contributed to make Rails development on Windows at least somewhat bearable. This road would be much harder without your help and every developer owes you a debt of gratitude.

Prepare Your App for Rails 4 and Ruby 1.9 »

Created at: 21.02.2012 21:59, source: Engine Yard Blog, tagged: ruby Technology

Well, it had to happen some day.

Pour one out for our dearly beloved Ruby 1.8.7. And if you’re still using 1.8.7 for your Rails app, pour yourself a cup of coffee—Rails 4.0 will run strictly on Ruby 1.9.

The Rails master branch was moved to 4.0 two months ago, almost 6 years to the date of the announcement of Rails 1.0, and the primary cited reason for doing so is to get everyone using Rails on Ruby 1.9.

It’s difficult to remember a time before Ruby 1.8; indeed, Rails grew up with it. Alas, it will be nice to get the Rails community over onto the same, faster release.

As you know, 1.9 is packed with lots to love. The performance improvements alone make it a worthwhile upgrade—its slick YARV interpreter helped Ruby shake off its slow poke stigma. Combined with native threading and fibers, use 1.9 correctly and you'll be able to implement noticeable speed-ups across your applications.

What's more, Ruby 1.9 is resilient to the hashing denial-of-service attack that was recently brought into the limelight.

Convinced it’s time to make the move yet? While there’s a whole litany of changes between Ruby 1.8 and Ruby 1.9, if you want to bring your code up to snuff these are some of the more common things you’ll have to tweak:

Block local variables

Ruby 1.8.7

irb(main):001:0> x = 33
=> 33
irb(main):002:0> 3.times do |y|
irb(main):003:0>   x = 'chop' * y
irb(main):004:0>   puts x
irb(main):005:0> end

chop
chopchop
=> 3
irb(main):006:0> x
=> "chopchop"

Ruby 1.9.1

irb(main):001:0> x = 33
=> 33
irb(main):002:0> 3.times do |y;x|
irb(main):003:0>   x = 'chop' * y
irb(main):004:0>   puts x
irb(main):005:0> end

chop
chopchop
=> 3
irb(main):006:0> x
=> 33

Hashes are ordered by insertion order

Ruby 1.8.7

irb(main):001:0> {:a => "a", :c => "c", :b => "b"}
=> {:a => "a", :b => "b", :c => "c"}

Ruby 1.9.1

irb(main):001:0> {:a => "a", :c => "c", :b => "b"}
=> {:a => "a", :c => "c", :b => "b"}

Or using new hash syntax

irb(main):002:0> {a: "a", c: "c", b: "b"}
=> {a: "a", c: "c", b: "b"}

Strings are indexable

Ruby 1.8.7

irb(main):001:0> "lemon"[1]
=> "101"

Ruby 1.9.1

irb(main):001:0> "lemon"[1]
=> "e"

{"a","b"} No longer supported

Ruby 1.8.7

irb(main):001:0> {"San Francisco", "California"}
=> {"San Francisco" => "California"}

Ruby 1.9.1

irb(main):001:0> {"San Francisco", "California"}
=> SyntaxError: (irb):1: syntax error, unexpected ',', expecting tASSOC

Array.to_s is to be taken literally

Ruby 1.8.7

irb(main):001:0> [2011, 2012].to_s
=> "20112012"

Ruby 1.9.1

irb(main):001:0> [2011, 2012].to_s
=> "[2011, 2012]"
irb(main):002:0> [2011, 2012].join
=> "20112012"

Multilingualization

Ruby 1.8.7

String is collection of bytes

irb(main):001:0> "해적선".size
=> 9
irb(main):002:0> "해적선".bytesize
=> 9

Ruby 1.9.1

String is collection of encoded characters

irb(main):001:0> "해적선".size
=> 3
irb(main):002:0> "해적선".bytesize
=> 9
irb(main):003:0> "해적선".encoding.name
=> "UTF-8"

In addition to making the appropriate modifications to your existing code, I would highly recommend that you get RVM running on your machine if you don't have it running already. You can use it to quickly toggle between different versions of Ruby as well as different gemsets, which can mitigate some migration pain. Being able to quickly toggle between versions of Ruby can help you pinpoint where unexpected errors are coming from.

Lastly, be sure to perform all of these updates in a separate branch. Should you encounter difficulties, it will be nice to know that a revert is only a command away.

So hop to it! Transitioning from Rails 3 to Rails 4 while simultaneously transitioning versions of Ruby is a task you don't want to face. The older You will appreciate it. Promise.

CFP for JRuby Conf 2012 is Now Open! »

Created at: 15.02.2012 01:11, source: Engine Yard Blog, tagged: community Open Source ruby

We’re very pleased to announce that the JRuby Conf call for papers is officially open. While we’re certainly looking for great stories about how you’re winning using JRuby, we also won’t mind a couple of proposals that fall outside the JRuby-sphere. If you feel passionate and want to speak about a project or topic that you think suits the mix of people that will be at JRubyConf, let us hear about it! We’re looking forward to a great event and can’t wait to see your proposals.

If you haven’t gotten your ticket yet, go ahead and get registered. If we accept your proposal and you already bought a ticket, let us know and we’ll refund the ticket right away.

Validations are behavior, associations are structure »

Created at: 13.02.2012 00:53, source: David Chelimsky, tagged: rspec ruby

TL;DR:

• TDD is about specifying behavior, not structure.
• Validations are behavior, and should be specified.
• Associations are structure, and need not be.

Disclaimer

This is my personal viewpoint, though it is not mine alone. YMMV.

Declarations

ActiveRecord provides a declarative interface for describing the structure and behavior of a model:

class Article < ActiveRecord::Base
  validates_presence_of :title
  has_many :comments
end

While syntactically similar, these two declarations do fundamentally different things.

Validations are behavior

The validates_presence_of :title declaration changes the behavior of the save method (and other methods that use save), and should be specified explicitly. Here’s an example using shoulda matchers:

describe Article do
  it { should validate_presence_of(:title) }
end

Even though the matcher’s name looks just like the likely implementation, the validate_presence_of matcher specifies that you can not save an Article without a non-nil value for title, not that the validates_presence_of(:title) declaration exists.

Associations are structure

The has_many declaration exposes a comments method to clients that appears to be a collection of Comment objects. Doing Test-Driven Development, you would add this declaration when a specified behavior requires it e.g.

describe Article do
  describe "#with_comments_by" do
    it "finds articles with comments by the submitted comment_author" do
      article = Factory(:article)
      article.comments << Factory.build(:comment, :author => "jdoe")
      Article.with_comments_by("jdoe").should eq([article])
    end
  end
end

This example needs a comments method that returns a collection in order to pass. If it doesn’t exist already (because no other example drove you to add it), this would be all the motivation you need to introduce it. You don’t need an example that says it "should have_many(:comments)".

Testing the framework

Some will argue that we don’t need to spec validations either, suggesting that it "should validate_presence_of(:title)" is testing the Rails framework, which we trust is already tested. If you think of TDD as a combination of specification, documentation, and regression testing, then this argument falls short on the specification/documentation front because the validation is behavior and, thus, the spec should specify the validation.

Even if you view testing as nothing more than a safety net against regressions, the argument still falls down in the face of refactoring. If we add a Review class that also has_many(:comments) and validates_presence_of(:title), and we want to extract that behavior to a Postable module that gets included in both Article and Review, we’d want a regression test to fail if we failed to include either of those declarations in the Postable module.

But declarations are already declarative!

Another argument is that declarations supply sufficient documentation. e.g. we can look at rental_contract.rb and know that it validates the presence of :rentable:

class RentalContract < ActiveRecord::Base
  has_many :monthly_charges
  has_one :rentable, :polymorphic => true
 
  validates_presence_of :rentable
 
  def default_monthly_charge
    price / months_applied
  end
end

This is an interesting argument that I think has some merit, but I think it would require an extraordinarily disciplined and consistent approach of using declarations 100% of the time in model files such that each one is the spec for that model, e.g.

class Contract < ActiveRecord::Base
  validates_presence_of :name
  has_many :monthly_expenses
  calculates_default_monthly_charge
end

100% may sound extreme, but as soon as we define a single method body in any one of the models, the declarative nature of the file begins to degrade, and so does its fitness for the purpose of specification. Plus, if we can only understand the expected behavior of a model by looking at its spec and its implementation, we’ve lost some of the power of a test-driven appraoch.

What do you think?

Do you spec associations? If so, what value do you get from doing so? If not, have you run into situations where you wished you had?

Same questions for validations.