My Disappointment with Google+

When Google+ first arrived, I jumped on the bandwagon very quickly and looked forward to moving my social activity over from Facebook to the new service. I'm a longtime Google fan, and their new aesthetic really appeals to me. Moreover, their concept of Circles is exactly what I wanted out of a single social sharing system.

I have three very distinct groups of people I interact with online, and rarely do these groups of people intersect. I share things with friends and family, with the Drupal community, and with indie game developers / enthusiasts. Until now, I've interacted with the first group over Facebook, the second over Twitter (and on, and the third on a variety of blogs (including my sparsely updated Rogue Wombat.

Rarely do I need or want to share something with all three groups of people. This means that friends and family / indie game developers and enthusiasts are likely to be annoyed by my constant stream of Drupal updates on Twitter. It also means I don't "friend" a lot of people on Facebook from the Drupal community unless I actually consider them people who might actually care about seeing notes about my adventures in parenting.

Out of nowhere Google+ comes along with the promise of being able to categorize everyone into one of these three circles and share appropriate updates with people in the different circles all through one service. It was too good to be true - in fact, as I said above it was exactly what I wanted at the time as Facebook's lists and default status update settings had really failed me.

So, what did I do? I set about adding the first couple hundred people I knew to my Drupal / Friends and Family circles. It was great - I could target updates appropriately and not worry about turning anyone off or sharing personal family photos with the internet at large. However, as my circles started filling up, my Google+ stream suddenly became nothing but noise. Any time I went to look at Google+, I saw posts in languages I didn't know from people who obviously weren't practicing selective sharing themselves.

The problem, though, is that I have to put someone into my Drupal circle if I want them to see my Drupal updates. In other words, I am forced to practice a "follow back" policy on Google+ if I want to target my updates, a practice which I stay well away from (e.g. I follow a mere 88 accounts on Twitter compared with the 2,461 that follow me). I just don't like a noisy stream - I only want to see posts I care about, but those posts could come from any of my main circle areas.

So, what to do? I could just make all my Drupal posts Public so I'm not forced to follow anyone random Drupaller back just so they can see relevant information from my account. However, then anyone I connect with for indie gaming and my family and friends will then see my Drupal posts, which will be uninteresting to them and create a bad experience for them on Google+. I don't want to do this to them.

A better suggestion I heard from Matt Butcher was that Google+ should allow you to make a Circle public so others can subscribe to it. Drupallers can just follow my Drupal posts and I don't even have to know about it, and I'd be free to follow those Drupallers whose posts I want to see in my stream. I really like this idea, though for recommendation and statistical purposes, it would still be useful to have those people taken into account even if I don't add them back.

I could just not use the stream any more - but that's always going to be the first thing I see when I open Google+. If that's the first thing I see, I'm not likely to go there any more. I can go see relevant posts on Facebook without any "work" (though lately I have to constantly re-sort my news feed to show recent posts first...). I could make yet another circle of people whose updates I want to read and just always switch to it, but that's always going to be my entire Friends and Family / Indie Gaming circles, so why should I have to maintain yet another circle just to make my stream interesting?

So, that sums up my disappointment with Google+. I really wanted it to be a platform for me to share targeted status updates with friends and Drupallers from around the world, but I can't do that and still make it useful for me. That means I rarely hop in there except to add someone back or post a quick status update. And if I'm not feeling the need to check it continually throughout the day, I'm much less likely to go to it to post updates - even with the status update box conveniently integrated into every Google service.

As much as I want to switch, I'm still mostly just on Twitter / Facebook and don't know when I'll be able to move further into Google+. Against the day that Google sorts this out, feel free to add me to your circles and I might just add you to mine. Wink

Shipping and product line item types in Drupal Commerce

In Drupal Commerce, a line item is any item added to an order that affects the order total. They represent products, shipping rates, certain types of discounts, and more. During sell price calculation for products and rate calculation for shipping, you actually apply discounts, fees, and tax rates as manipulations to the unit price of line items.

I've been dealing a lot with line items during a personal shipping sprint I've been on the last week and a half to help launch a client site. That work has involved a complete rewrite of Commerce Shipping in the 2.x branch to support carrier calculated rates (such as those returned by ConnectShip, UPS, FedEx, etc.). That work in turn has resulted in the release of a Physical Fields module that defines weight and dimensions fields and a Commerce Physical Product module that provides API support for determining when orders contain shippable products, the total weight of the order, and other useful things.

Once this site launches, I'll give more attention to the upgrade path for folks using Shipping 1.x to move up to Shipping 2.x. (I'll also need to rewrite the flat rate shipping method to go along with it.) To push forward integration with different carriers, we'll be holding a Shipping Sprint at DrupalCamp Atlanta, fittingly the corporate home of UPS.

During the course of my work on Commerce Physical Product, I was reminded that determining whether or not a line item represents a product isn't as straightforward as you would first think. It's nothing terribly tricky, but you can't just perform a simple check on the product type to reliably determine if a line item represents a product.

This is insufficient:

if ($line_item->type == 'product') {
// ...

The reason is Drupal Commerce allows you to have multiple product line item types, each with their own unique fields that may be exposed through the Add to Cart form. This feature lets you sell customizable products where the various customizations are stored with the product reference in the line item.

A simple use case is adding a custom price field to a donation product line item type allowing customers to tell you how much they want to donate to a specific campaign. This can all be configured through the Field UI and Rules, mitigating the need for modules like UC Variable Price. Trés cool.

Since you can have multiple product line item types, we provide a helper function that returns an array of the names of every product line item type defined on the site. Instead of the code above, you can perform an in_array() check on the type of a line item to see if it is of any of the valid product line item types:

if (in_array($line_item->type, commerce_product_line_item_types())) {
// ...

Any time you're writing code that should apply to a product line item, be sure to use this method instead of the first. Hope that helps you as you work on your Drupal Commerce contribs and custom modules. I almost forgot about this when writing Commerce Physical Product. Granted, I haven't been sleeping much recently, but if it's that easy for me to forget, I bet it's a bit unknown to the general public.

Giving Credit Where Credit is Due

One of the best things you can do for your project is highlight the contributors who are helping make it a success. Every patch counts, and every now and then you get someone in the queue who blows you away with a first patch that traces down some sneaky, hidden bug that you know took hours to track down. Attributing such patches has always been a matter of dropping the contributor's name into a commit message and thanking them in the issue in the past, but thanks to Git on there is now a better way.

This may be old news for most folks, but I didn't discover this feature until just a couple months ago. It turns out that user profiles on now include a Git attribution heading under which you can find the appropriate command line option to pass to git commit to attribute that user with a patch.

Attributing svendecabooter

By way of example, I recently committed a patch submitted by svendecabooter. I still formed my commit message using the tried and true format (including both the issue number and his username), but I also added the indicated text to the command:

git commit --author="svendecabooter <>" -m "Issue #1197512 by svendecabooter: pass the entity rendering language down to the linked fields when rendering product fields."

Thanks to Git, even though I am the one committing the code, he is the one credited with authorship of it. This is visible both in the log for that commit and on the committers page for Drupal Commerce. Many thanks to the team for working this all out and helping maintainers give credit where credit is due.

Minding my Peas and Queues

As it turns out, I really enjoyed my time in London. Getting to visit old, historic cities is quite a treat for someone from the Midwest in the U.S.A. There are no castle towers on hills or centuries old steeples gracing my skyline in Louisville, KY, and I'm quite a sucker for both. Getting to visit the Tower of London, which supplies arms to my local museum, turned out to be a special treat. I'm also a sucker for good food and drink (who isn't?), and while it's not the height of elegance, my first experience of fish and chips with mushy peas was good, too. Note to Americans: it's mush-y, not moosh-y.

Fish and chips with mushy peas. Mmm!
Fish and chips courtesy of The George.

My first couple of days in London were my busiest. I delivered a Drupal Commerce training to a room full of students with Greg Beuthin (a.k.a. smokinggoat), our in-house trainer par excellence. Unfortunately, he and I both had sniffles and scratchy throats, so I can only imagine what those reviews will say about our delivery... C'est la vie. We survived, but my day was only just getting started by the end.

For most of the next day and a half I was minding my queue in preparation for the 1.0 launch of Drupal Commerce. With the help of Bojan Zivanovic and Damien Tournoud (and a few others throughout the day), we were able to close out a variety of issues and ensure all of our automated tests were passing when we finally packaged the 1.0. In a feat of endurance sure to be remembered for ages to come, Damien and I outlasted Bojan's youthful energy to finalize the release after postponing dinner for a couple hours. That's what experience gets you, folks.

Excited Damien
An excited Damien is never too hungry to celebrate.
Proud father
It's a boy! He weighs 8 lbs. 6 oz. and is 22" long!

Coming to DrupalCon to collaborate with the other Commerce Guys and the various contributors from across Europe was the greatest part for me. Without the community, we wouldn't have the 1.0 that we do, a solid e-commerce framework that is not limited to a particular use case or locality. We're standing on the shoulders of Drupal core, the contributions of Merfago, and the dozens of patch contributors who have helped ensure Commerce can accommodate all those crazy taxes around the world. I also personally wouldn't have known that mushy peas are better with malt vinegar mixed in without John Albin Wilkins.

With the 1.0 out, my attention is now focused on ensuring our essential contributed modules are ready for use. I'm focusing specifically on making product administration simpler, ensuring Commerce Shipping supports calculated shipping quotes, and pushing code upstream from a local project into Commerce Addressbook. I always have a half dozen payment related projects in the works, too.

If you want to hear more about Drupal Commerce in person, I'll be talking about the project as an international community success story at DrupalCamp Atlanta. I'm busy compiling statistics on committers and contributions to share along with my usual hand-waving, mile-a-minute overview of the modules' functionality.

I'll also deliver a show-and-tell style training at this year's Do It With Drupal in NYC. I love DIWD as a more intimate gathering of module authors, core contributors, and web pros from outside the Drupal community. It's a great place for attendees to soak in a wealth of information and run their project needs by the folks writing the code they'll use. Today is the last day for early bird pricing, so if you're on the fence, you may as well make the impulse buy and come hang out in New York with us.

I hope to see many of you at those events and many more minding the queues.