Tasting notes on the French Broad IPA

So, I'm hanging out at my favorite pizza place in Boone, Capone's Pizza, drinking a beer from a brewery about 2 hours south of here. They put this beer on tap about two weeks ago and it's became my goto IPA.

Appearance

This beer has a golden/amberish color, white head and decent lacing.

Smell

It smells like fresh baked bread and earthy hops, little notes of caramel, pine, and a bit of citrus.

Taste

Nicely balanced with a lot of biscuit, earthy hops, touchs of citrus and a piney ending. It's a supper well balanced IPA, and for being at least 3 weeks old it is still has a nice hop profile.

Mouthfeel

It's decent, not too thin but not very heavy.

Overall

I like this beer, it really shows off what French Broad can brew. I can't say I haven't had a beer they brew that I didn't like.it's a good goto IPA.

Final score

4 out of 5

Tasting notes on the American Brewing Caboose Oatmeal Stout

Yesterday I stopped by Peabody's after work and picked up a few stouts, one of which is a 22 of American Brewing Caboose Oatmeal Stout. I'm a big fan of stouts so I figure I would give it a shot, Beer Advocate rates it at an 89.

Appearance

The beer pours pitch black with about 3 fingers of really dark head. The head retention is pretty much non-existent and there isn't really any lacing.

Smell

It smells like chocolate malt, carmel, and not much else.

Taste

Disappointing to be honest. It tastes very sweet, a bit of coffee, metallic, but you don't get much alcohol. There's a little bit of fruit in it, but still it's very lacking. It's not very balanced, the hop profile is non-existent.

Mouthfeel

Not as heavy as it should be, the oatmeal should give it more body but it's very watery. The carbonation is way too heavy, it's almost like drinking a soda.

Overall

I don't care for this beer and won't be buying it again. It was really disappointing and a bit of a let down for the first beer I tried from this brewery.

Final score

2.5 out of 5.

Automate your twitter posts with views bulk operations, twitter module, and rules scheduler

Have you ever wanted to make your Drupal site tweet about random stuff? I did and I need to do it for an upcoming project. It's really not too difficult to accomplish this task with views bulk operations, the twitter module, and rules scheduler.

Required modules

Setting up your VBO View

The first thing you need to do is create a view that provides the list of nodes we want to tweet about but doesn't have a Page or Block display. We're only going to be using this view to provide data to rules scheduler.

Then you need to add a Bulk operations: Content field to the view and some filter criteria.

Creating the Rules Component

After you save your view you go to the Rules then Components page and click "Add new component" link on the top of the page. Select Action set as the Component plugin then click continue. After that give it a name and tags, we won't need to use variables.

After that you can start setting up your rules. Rule components (Action set) are like rules but they do not have any Events associated with the rule, that's where the Rules Scheduler module comes in. First we're going to need to setup our action to load the data from the views bulk operations view we created earlier. Select the 'Load a list of entity objects from a VBO View." under the dropdown.

Next select the View and Display you want to use for this Component, you can also send arguments to your view that supports tokens. You can also change the Variable label and Variable name for the results of the view if you want to.

After that you need to add a loop action to the Component that will loop threw the results of the view.

Then inside that loop we need to add an action, we're going to use the "Post message to Twitter" action from the Twitter module.

After that we need to setup the message, you can use token to create this and select the Sender account you want to tweet from.

After that we need to add one more action to the Component. We're going to create an action for the Rules Scheduler to "Schedule component evaluation", which basically means run the rule and schedule to run it in N number of minutes/seconds/hours/etc.

Then select the Component you want to use:

And finally schedule the evaluation date, you can do this with a fixed time or use a format that the strtotime() function can consume.

You should end up with something that looks like this:

After that you can execute the Component from the Components page:

The end result

After it runs for the first time you should see an entry on the Schedule page for it and it should have tweeted.

You may have to adjust your cron settings to make this work properly, the rule is only triggered when cron runs.

Using git format-patch to generate better patches for your Drupal projects

One thing that bothers me about how the developer documentation is how it suggests that you should use git diff to generate your patches. That's all well and good if you have a maintainer of a project who comments the commit properly, but most of the time that doesn't happen.

When you run git diff on a repo you get output that looks like this:

$ git diff 6e04143743 --color=never
diff --git a/drupal-org.make b/drupal-org.make
index 1fda437..9429e81 100644
--- a/drupal-org.make
+++ b/drupal-org.make
@@ -1,7 +1,7 @@
 api = 2
 core = 7.x

-projects[ctools][version] = "1.2"
+projects[ctools][version] = "1.3"
 projects[ctools][subdir] = contrib

 projects[date][version] = "2.6"

That certainly is a patch, but it tells you nothing about authored the code or when it was committed.

If you use git format-patch to generate the same diff you end up with something like this:

$ git format-patch 6e04143743 --stdout
From 15936028741df0038d0f2065f0c2b09bdf2a5bd3 Mon Sep 17 00:00:00 2001
From: Zach Seifts 
Date: Wed, 3 Apr 2013 15:41:01 -0400
Subject: [PATCH] Fixes issue #1960476, Update ctools module to 7.x-1.3

---
 drupal-org.make | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drupal-org.make b/drupal-org.make
index 1fda437..9429e81 100644
--- a/drupal-org.make
+++ b/drupal-org.make
@@ -1,7 +1,7 @@
 api = 2
 core = 7.x

-projects[ctools][version] = "1.2"
+projects[ctools][version] = "1.3"
 projects[ctools][subdir] = contrib

 projects[date][version] = "2.6"
--
1.8.2

You end up with a whole lot more information about the commit in your patch. This way when you use git am to apply the patch you get the actual commit with the proper person attributed for their work.

Rendering responsive images with field_view_field and the Picture module

I've been working on implementing our theme in Drupal 7 and making it responsive. There are a lot of great modules out there that can help you do this, right now I'm using response.js, Omega, Breakpoints, and Picture.

One thing I've came across a few times is rendering image fields and making use of the Picture module.

$header_image = field_view_field('node', $vars['node'], $header_key, array(
  'label' => 'hidden',
  'type' => 'picture',
  'settings' => array(
    'picture_group' => 'NAME_OF_PICTURE_GROUP',
    'fallback_image_style' => 'NAME_OF_FALLBACK_IMAGE_STYLE',
    'image_link => ''
  )
);

The field_view_field function makes it really easy to render fields. I'd also take a look at hook_field_formatter_info and hook_field_info for more info on how to use the field_view_field function. Also checkout a post called Responsive Images: A Drupal Implementation that describes a great way on how to setup Breakpoints, Picture and your Image Styles. You can also export all of the configuration in a feature.