Our Blog

Batteries Included!

By Mike Farmer
April 4, 2013

How many gems does it take to build an app? Many gems duplicate functionality that’s already in ruby core or in the standard library. Daniel Huckstep reviews some goodies that come with ruby that you could probably use to replace some of those gems.

Basics

• Set: Like an array but only allows unique values. Set also optimizes for the include? method so if you are calling include? a lot on your arrays and you don’t require duplicates, Set will be a much better option for you.

• Enumerable: Gives you map, each_with_index, and all the other goodness that comes with the Enumerable class. All you need to implement is each and you get everything else in Enumerable for free.

• Enumerator: Allows you to build your new enomerators on the fly and implement lazy loading.

• SimpleDelegator: Inherit from SimpleDelegator and then set self and it will delegate any missing methods to the underlying class.

• Forwardable: Forward selected methods to another object

Performance

• Benchmark: Allows you to measure the performance of blocks of code. It also has many different outputs and reporting formats.

• RubyVM::InstructionSequence: Set compile options to optimize things like tailcall in recursive …

Code Smells: Your Refactoring Cheat Codes

By Mike Farmer
April 4, 2013

Code smells are heuristics for refactoring. Resistance from our code are hints for refactoring. John Pignata shares some great tips on how to actually go about refactoring a long method. Here are some of the highlights and steps that were covered.

First:

• Wrap entire method in a class
• Promote locals to instance variables

Second:

• Move the work into private methods

Third:

• Look for multiple responsibilities in the class
• Create new classes and adjust interfaces so everything still works

Fourth:

• Wrap your lower levels of abstraction (IO, Sockets).

Fifth:

• Your class may know too much about your lower level abstractions. Find ways to remove that knowledge using design patterns such as Observer/Listener.

Sixth:

• Look for case statements or other big conditionals
• Replace conditionals with polymorphism
• Move the conditional to a factory if applicable

Seventh:

• Remove data clumps such as knowledge of indexes in arrays or arrays of arrays (data[1][2]).

Eighth:

• Remove uncommunicative names such as “data” and “new”

Ninth:

• Look for variables that have same name but different meaning such as local variables that match instance variables.

Tenth:

• Look for nil checks. Look for …

Converting RHEL 5.9 and 6.4 to CentOS

By Jon Jensen
April 4, 2013

CentOS is, by design, an almost identical rebuild of Red Hat Enterprise Linux (RHEL). Any given version of each OS should behave the same as the other and packages and yum repositories built for one should work for the other unchanged. Any exception I would call a bug.

Because Red Hat is the source or origin of packages that ultimately end up in CentOS, there is an inherent delay between when Red Hat releases new packages and when they appear in CentOS. CentOS is financed by optional donations of work, hosting, and money, while Red Hat Enterprise Linux is financed by requiring customers to purchase entitlements to use the software and get various levels of support from Red Hat.

Thanks to this close similarity and the tradeoff between rapidity of updates vs. cost and entitlement tracking, we find reasons to use both RHEL and CentOS, depending on the situation.

Sometimes we want to convert RHEL to CentOS or vice versa, on a running machine, without the expense and destabilizing effect of having to reinstall the operating system. In the past I’ve written on this blog about converting from CentOS 6 to RHEL 6, and earlier about converting from RHEL 5 to CentOS 5.

I recently needed to …

Immutable Ruby by Michael Fairley

By Mike Farmer
April 4, 2013

Michael Fairley is presenting on Immutable objects in ruby.

Immutability is a term used to describe data or objects that can’t be changed. This is a lesser known concept for ruby developers because almost everything in ruby is mutable. Despite this, much of ruby is full of immutable code. Make it explicit. Even in your databases there are some records you don’t want to modify.

One technique to making your database records immutable is to use the readonly? method in ActiveRecord or to revoke the permission to modify at the database level.

Many objects can utilize the freeze method which ensures that objects aren’t being modified. For example, use freeze for configurations. Be aware though that freeze doesn’t freeze objects in an array or hash so you’ll need a gem that provides the ability to deep freeze.

The gem values, provides a set of data structures that are frozen by default. These can be useful in cases where you might use Struct. You can create the object but it doesn’t allow you to change the attributes.

Use value objects in your ActiveRecord object by using composed_of which lets you use an object to combine attributes of the record into a value object. This gives you …

It's Time Once Again for MountainWest RubyConf!

By Mike Farmer
April 4, 2013

It’s one of my favorite times of the year. This will be my third trip to Salt Lake City to attend Mountain West Ruby Conference. One of ther really great things about developing in ruby is the amazing community. Hanging out with fellow developers and enthusiasts is very envigorating and so much fun.

This year I will be blogging on all the talks and reporting on some of the great stuff that will be presented. You can checkout the MWRC Schedule to see some of the great speakers in the lineup. You can follow the #mwrc tag on twitter to follow this amazing conference.

MWRC Ruby 2.0 with Matz

By Mike Farmer
April 4, 2013

Today’s first speaker at MWRC is the one and only Yukihiro Matsumoto, better known as Matz. Matz is the founder and chief architect of Ruby. Matz has a wonderfully friendly personality. His talks are always filled with humor.

Probably not unexpectedly Matz is talking about Ruby 2.0. Ruby 2.0 is the happiest ruby release ever. He outlined some of the new features in Ruby 2.0 as follows:

Features of 2.0

• It’s faster than 1.9

• 100% compatible with 1.9

• Keyword Arguments: Keywork arguments provide support for literals at the end of the arguments: log(“hello”, level: “DEBUG”) You can implement keyword arguments in 1.9, but 2.0 makes it simpler to read and write and implement

• Module#prepend: Module#prepend is kind of like alias_method_chain from Rails but it doesn’t use aliases.

  The prepend method evaluation comes before the existing methods but after the includes so that you can more easily extend existing methods. And you can package changes into a single module.

• Refinements: Currently, monkey patching is a common practice in ruby. But, monkey patching is difficult to scope because it is global. This often leads to name spacing problems and difficult …

Testing Anti-Patterns

By Mike Farmer
April 4, 2013

Testing is always a popular subject at MountainWest RubyConf. Now that many developers are embracing test driven development, there is a big need for guidence. Aja Hammerly is talking about testing anti-patterns. Tests should be trustworthy. You should be able to depend on them. If they fail, your system is broken. If they pass your system works. Tests should be simple. Simple to read, simple to write, simple to run.

Here are some anti-patterns that Aja addressed:

Pointless Tests

• No tests! Solution: Write tests.
• Not Running Tests. Solution: Use Continuous Integration so you have to run your tests.
• Listen to your failing tests. Fix team culture that ignores a red CI.
• That test that fails sometimes. Fix it!

Wasted Time / Effort

• Testing Other Peoples Code (OPC). Solution: Test only what you provide and use third-party code that has good coverage.
• assert_nothing_raised or in other words, don’t assert that a block runs without an exception only. If an error is raised, it will just raise an exception, which is a failure.

False Positives and Negatives

• Time sensitive tests. For example, using Time.now. Solution: stub Time.now().
• Hard-coded dates in tests. Use relative dates instead. …

Deploying password files with Chef

By Matt Vollrath
April 3, 2013

Today I worked on a Chef recipe that needed to deploy an rsync password file from an encrypted data bag. Obtaining the password from the data bag in the recipe is well documented, but I knew that great care should be taken when writing the file. There are a plethora of ways to write strings to files in Chef, but many have potential vulnerabilities when dealing with secrets. Caveats:

• The details of execute resources may be gleaned from globally-visible areas of proc.
• The contents of a template may be echoed to the chef client.log or stored in cache, stacktrace or backup areas.
• Some chef resources which write to files can be made to dump the diff or contents to stdout when run with verbosity.

With tremendous help from Jay Feldblum in freenode#chef, we came up with a safe, optimized solution to deploy the password from a series of ruby blocks:

pw_path = Pathname("/path/to/pwd/file")
pw_path_uid = 0
pw_path_gid = 0
pw = Chef::EncryptedDataBagItem.load("bag", "item")['password']

ruby_block "#{pw_path}-touch" do
  block   { FileUtils.touch pw_path } # so that we can chown & chmod it before writing the pw to it
  not_if  { pw_path.file? } …