CustomInk technology is very excited to welcome one of our new summer interns, Sukhata Kulkarni.

The HolyGrailHarness is a curated Rails application prototype that focuses on simple test patterns for Ruby & JavaScript!

Unlike normal Rails Application Templates or more modern Rails application generators like Rails Composer, the HolyGrailHarness is a basic Rails application that can be considered a prototype and customized via a simple setup script. It is also somewhat opinionated in that it promotes simple and powerful testing choices and focuses on using Ruby 1.9 and up, MiniTest::Spec, Capybara, Poltergeist/PhantomJS, and Konacha. More details on each component and what HolyGrailHarness provides are below.

The HolyGrailHarness is perfect for any of the following:

• Bootstrapping your next Rails application.
• Learning and promoting MiniTest::Spec
• Modern JavaScript testing setups.
• Teaching Rails and/or JavaScript at your next meetup.

CustomInk technology is very excited to announce that Ken Collins has joined the team!

We recently ran into a situation where we needed to use Chef Search to modify our /etc/hosts file dynamically on each Chef run. Originally seeming to be a relatively simple task, managing the hosts file with Chef rose some interesting challenges. While there are a few existing community-maintained /etc/hosts management cookbooks out there, none of them suited our needs. We wanted a highly customizable, easily expandable, simple, LWRP that was idempotent.

In this post, I will discuss creating your own LWRP, as well as some of the challenges faced while writing this LWRP. There will also be links to the community LWRP that we’ve created.

Throughout my internship at CustomInk, I’ve put a significant focus on Chef cookbook testing. At the time of this writing, there are a few solutions for testing cookbooks - ChefSpec, cucumber-chef, minitest-chef-handler, and rspec-chef – and they each have their own distinct advantages. At the very least, you should run knife cookbook test and foodcritic against all your cookbooks. Nathen Harvey covered this in his MVT: knife test and TravisCI blog post.

At CustomInk, we test using ChefSpec. Additionally, we use some home-grown gems such as fauxhai and Strainer to make testing easier.

At CustomInk, we recently made the switch to a new DNS provider. During the switch, we mass-imported records from our existing provider to our new provider. Did we get them all? Are they live yet? The immediate solution was to open up the terminal and fire off cURL requests, but there had to be a better way…

In this post/tutorial, I will show you how I created a test suite for our DNS records using RSpec. The solution is amazingly simple, and your specs will only be about 7 lines of code!

In Provision your laptop with Chef: Part 1, I showed you how to setup your free Opscode Chef account and register your local development machine as a client. In Part 2, we will explore a few handy ways to manage and provision your new or existing laptop with Chef. Whether it’s creating users, installing applications, or always having the perfect desktop background, Chef can make it happen!

Part 2 of this series assumes that you have successfully completed all of the steps in Part 1. If you have not yet completed Part I, please do so before continuing.

We had a fairly severe production issue the other day. The kind of issue where you get sick to your stomach as you begin to realize what…just….happened……

As the issue escalated, news spread and a core group of people took control to work towards a resolution. The questions were always “what’s happening” and “what’s changed recently” and “what kinds of things might cause this” and never “who deployed last” and “who worked on this code originally”. It says a lot about a person that can keep their cool and focus on issue resolution instead of blame assignment. Even when your tired, punchy, and irritated because you can’t figure out exactly what’s going on, keeping your cool is ultimately the key to success.

In my last post, MVT: Foodcritic and Travis CI I described the process for having Travis CI look after your cookbooks and run Foodcritic, the cookbook lint tool, on your cookbook after each git push. In this post, we’ll iterate on the “Minimum Viable Test” idea by adding in support for knife’s cookbook testing.

Wait, I’m already running foodcritic, do I really need to run knife cookbook test, too?

I’ll use a very simple example to demonstrate that you do.

Let’s create a very basic cookbook:

1
2
3
4

knife cookbook create very_basic
** Creating cookbook very_basic
** Creating README for cookbook: very_basic
** Creating metadata for cookbook: very_basic

Next, we’ll write a flawed recipe:

1
2
3
4

package "flawed" do
  action :nothing
end
end

Now, run foodcritic on this cookbook:

1

foodcritic cookbooks/very_basic

Foodcritic doesn’t throw any errors or find any problem with the cookbook.

Let’s try testing it with knife:

1
2
3
4
5
6

knife cookbook test very_basic
checking very_basic
Running syntax check on very_basic
Validating ruby files
FATAL: Cookbook file recipes/default.rb has a ruby syntax error:
FATAL: /Users/nharvey/projects/chef-hosted/.chef/../cookbooks/very_basic/recipes/default.rb:22: syntax error, unexpected keyword_end, expecting $end

OK, it should now be obvious that knife cookbook test should be included as part of our MVT.

Let me start off by apologizing to Dan for such a belated welcome post. It is belated for good reason though. Normally we mark our new engineer’s first deploy. Today does not mark Dan’s first deploy to production. But today’s deploy is the culmination of many deploys. And, it has been the one I’ve been waiting for.