Blog

Initial impression of the Hamshield

Posted on: 2016-05-23 09:12:32

Background and Intro

The Hamshield was a Kickstarter that ended sometime last summer. The original expected delivery date was October of 2015, but due to issues with manufacturing and a problem with their amplification circuits, it was delayed. I won't go into the details here, but you can read it on their Kickstarter page:

<iframe width=\"640\" height=\"360\" src=\"https://www.kickstarter.com/projects/749835103/hamshield-for-arduino-vhf-uhf-transceiver/widget/video.html\" frameborder=\"0\" scrolling=\"no\"> </iframe>

They started shipping about 3-4 weeks ago.

I got my Hamshield about 2 weeks ago. I was wanting to do more with it once I got it, but we're in the process of moving (and since it required some assembly & soldering) it had to wait until I could bust out the old soldering iron before I could do anything with it. Anyway, here are my thoughts and initial impression.

Assembly

Soldering on the headers wasn't bad at all. Once I got started, it took about 5 minutes to work through them. The GND pins by VIN didn't seem to want to solder very well at all. But everything else went very quickly.

The GND pins needed more love

The SMA connector was a bit much for my little 15 watt iron. Of course, all I had was a fine-tip on my iron, so a bigger tip would work much better on the SMA. My suggestion is to get the two pins on the back first, since they are smaller and tinned and tacked down much more easily than the pins on the tip of the board. I've got a 20W iron somewhere and I'll probably resolder this once I find it and put a bigger tip on it.

The only other "gripe" I had about the SMA jack (and this is really just due to my lack of a good tool) is that there are components really close to the jack. I'm talking about C19 and R9, specifically. It was tough to get the iron good and close to the pins. Take a look:

SMA pins did not solder well and there were components very close to them

The only other real thing that bothered me was the proximity of the headers near the USB port on the Uno:

Close-up of the header pins and the USB jack on the Uno

I stuck a piece of electrical tape on there just to be safe. It looks a little close for comfort.

Oh, and one other note. My shield didn't come with pass-thru headers... like most shield would have so that you could stack them. Not sure if that was a mistake or not, but it would be nice.

Using the Examples

The folks over at Enhanced Radio Devices provide an Arduino library on Github so that you can use and build stuff with your new shield.

Out of the box, I couldn't get the libraries to compile. I've submitted a pull-request to fix the issue, which appears to just be a pre-processor define that uses a hyphen in the name.

Once that was fixed, I was able to get the FMBeacon example loaded and going on the device. The audio was a bit anemic, but it does work:

<iframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/6DUnz-QK69Q\" frameborder=\"0\" allowfullscreen></iframe>

However, many of the other examples did not compile, JustTransmit does not work and some of the other ones do not work on Uno due to memory constraints.

There is also a reference in some of the applications to a PCM.h. There doesn't appear to be any documentation of what that is, specifically, but there are some PCM libraries for Arduino. So perhaps those would work.

Review

Well, I'm still excited about using the Hamshield. Though, it still seems like there is much to be cleaned up in the Arduino library and example applications. It'd be nice to be able to test things a bit better and I'm regretting not getting some sort of case for it since a 5W transmitter within a couple of feet will cause the unit to reboot. (I was trying to test the RSSI readings and it would just reboot while I tried this using a Baofeng HT).

Personally, I'd recommend getting some SMA pigtails and using that instead of the supplied antenna, but it will work in a pinch. It's hard to handle this thing with the antenna fully extended.

That's all for now. Thanks Casey and the folks at ERD for their efforts—looking forward to using it in my first real project!

Continue reading...

Importing a price in Drupal 8 for Drupal Commerce 2.x

Posted on: 2016-04-20 14:21:04

Just a quick note that if you're importing a Commerce price:

  • you must set the currency_code.

  • what was commerce_price in DC 1.x / Drupal 7 is now just price.

  • the number can be a decimal now.

    'price/number': SomeFieldName 'price/currency_code': plugin: default_value default_value: 'USD'

Note that you can also set up a constant in the migration definition and use the constant value:

source:
  plugin: d6_ubercart_product_variation
  constants:
    currency: USD
...
process:
  'price/number': SomeFieldName
  'price/currency_code': 'constants/currency'

It is worth mentioning that this fails silently right now. That is, if you don't provide the currency code, the migration will continue but you just won't have a value.

Update 2017-11-20: Vimokkhadipa told me that price/amount in the example above should actually be price/number. Since I haven't done any migration work in a while I'm taking his word for it and noting the update. Thanks Vimokkhadipa!

Continue reading...

You can chain callbacks in a Drupal 8 migration

Posted on: 2016-04-20 09:08:53

If you're wanting to do some advanced processing (e.g. lowercasing a word and then capitalizing the first letter) you can chain the two callbacks to get the desired effect:

process:
  name:
    -
      plugin: callback
      source: MyVar
      callable:
        - '\\Drupal\\Component\\Utility\\Unicode'
        - 'strtolower'
    -
      plugin: callback
      callable:
        - '\\Drupal\\Component\\Utility\\Unicode'
        - 'ucfirst'

The two transformations will take place one after the other. The first one will execute and pass in the value straight from the source (e.g. 'SOMEVAR'). The next one will get the result (e.g. 'somevar') and then the the final value will be ('Somevar').

Continue reading...

Quickly importing new config entities from the command line using Drush

Posted on: 2016-04-18 13:58:03

Drush's cset command is a bit picky, but with a few command line options, we can get it to import a yaml file into our site's config:

drush -y --format=yaml cset config.entity.string '' - < config_file.yml

This will put the entirety of config_file.yml into the configuration entity config.entity.string.

The -y is required because drush will ask you if you want add a new entity (and of course you do!). The "trick" if it even is that, is the '' before the - to read from STDIN.

Continue reading...

Field Tools as a replacement for Features

Posted on: 2016-04-04 12:28:56

One of my new favorite modules recently has been Field Tools. What I love about it is that it presents you with the ability to export all of the fields on a particular bundle (or even just a single field).

Then, you can just use field_create_field or field_create_instance in a little loop.

Take for example (in a module's .install file):

<code lang="php"> function mymodule_install() { $fields = mymodule_get_some_fields();

foreach ($fields as $name => $field) { field_create_field($field['field']); field_create_instance($field['instance']); } }

Then, inside of mymodule_get_some_fields() you just put the output of Field Tool's export:

function mymodule_get_some_fields() {
  $fields = array();
  // Start export.
  $fields['field_name'] = array(
    'field' => array(...),
    'instance' => array(...),
  );
  $fields['another_field_name'] = array(
    'field' => array(...),
    'instance' => array(...),
  );
  // End export.
  return $fields;
}

See, the magic is that the $fields export includes two sub-arrays: 'field' and 'instance'. That's what then powers the ability to just run it through the foreach above and it create your bases and your instances.

A couple of caveats:

  • You should probably check to see if the field exists before creating it. Otherwise, it'll throw an Exception.
  • It dumps everything in the exports, and so you might need to clean them up a bit by checking to ensure that you're not adding them to extra bundles or something like that.

But for most cases, this is way simpler than using Features and having to bring it in as a dependency.

Continue reading...

A quick note about Drupal Commerce price updaters that use Feeds and Feeds Validation

Posted on: 2016-03-31 14:25:21

Perhaps this may save someone else some time:

If you're wanting to do price updating in Drupal Commerce using Feeds, you'll normally use a field that is guaranteed unique. The Product ID and Product SKU fields (provided by the Commerce Feeds module) give this to you out of the box, but if you're wanting to give a user the ability to match by something else: say, a catalog number or some vendor part number that is an actual field on the product entity itself, you might have already looked at Field Validation to do this.

The general idea goes like this:

  1. Set up field validation so that the field you're wanting to use has the "Unique value" validator.
  2. Now, in Feeds, that field will show as being able to be used as a unique field.

This works for fields that are used on a single entity bundle, but not for fields that are used on multiple entities.

The problem arises when it tries to read the configuration for the bundles out of the field_validation_rule table. It might work if you have it defined for every instance of the field on every bundle, but I haven't tried that.

Make your life easier by just using Feeds Tamper String2ID, and creating a view that does a lookup from whatever field you're wanting to match with to the Product ID. Then, let Commerce Feeds' ProductProcessor do the rest.

Continue reading...

Modifying distribution Makefiles within your own project Makefile on Platform.sh

Posted on: 2016-02-24 09:48:42

As I've written about in the past, Platform.sh's Makefile build system is pretty sweet. One of the things that confuse me the most, however, is how to make a change to a distribution (such as adding a patch) without making things even more complicated.

Hat tip to Tavi Toporjinschi for writing the original example this is based off of.

Let's say for a moment that you want to add a patch to a module included in a distribution. If you're just starting out, you could actually just override the module and add it to sites/default/modules by including it within your existing file like so:

projects[commerce_paypal][version] = \"2.3\"
projects[commerce_paypal][patch][2082691] = \"https://www.drupal.org/files/issues/2082691-24-support_paypal_adaptive_payments_-chained_0.patch\"

However, if you're wanting to change a module that you've already been using, you'll want to modify the distribution directly from within your Makefile.

To do this, start by grabbing a copy of the distribution's git repository (and make sure you're working from the same version that you're using in your Makefile!). Here's instructions for Commerce Kickstart. Once you've done that, open up drupal-org.make which is the main Makefile for Commerce Kickstart.

In this particular instance, what I'd like to do is use the -rc4 version of Commerce Message. So I'll go ahead and make that change by finding the line that says:

projects[commerce_message][version] = 1.0-rc3

It will now read:

projects[commerce_message][version] = 1.0-rc4

Now that I've got my change and I've tested it (which I'm skipping for now), it's time to add it back into my project. To do this, we'll grab a diff of the change:

commerce_kickstart$ git diff > commerce_message_to_rc4.patch

The file commerce_message_to_rc4.patch will look something like this:

diff --git a/drupal-org.make b/drupal-org.make
index 45fef75..b497a53 100644
--- a/drupal-org.make
+++ b/drupal-org.make
@@ -48,7 +48,7 @@ projects[commerce_moneybookers][patch][] = \"http://drupal.org/files/commerce_mon
 projects[commerce_paypal][version] = 2.3
 projects[commerce_paypal][patch][2458721] = \"https://www.drupal.org/files/issues/commerce_paypal-addressfield-default-values-2458721-1.patch\"
 projects[commerce_backoffice][version] = 1.5
-projects[commerce_message][version] = 1.0-rc3
+projects[commerce_message][version] = 1.0-rc4
 projects[commerce_search_api][version] = 1.4
 projects[commerce_add_to_cart_confirmation][version] = 1.0-rc2
 projects[commerce_kiala][version] = 1.0-rc1

To add this to my project, we'll create a patches/ directory within the project (if it doesn't already exist) and copy that patch into the directory.

commerce_kickstart$ mkdir ~/Platform.sh/myproject/repository/patches commerce_kickstart$ cp commerce_message_to_rc4.patch ~/Platform.sh/myproject/repository/patches/

Now, we just need to patch the distribution within the Makefile. How do we do that? With a patch, of course! You probably have a line like this in your makefile:

projects[commerce_kickstart][type] = core

This downloads the "core" version of Commerce Kickstart. This is the one that you get when you download directly from Commerce Kickstart's module page or when you download commerce_kickstart-7.x-2.33-core.tar.gz from the releases page.

This will then be replaced with the following:

projects[drupal][type] = core
projects[commerce_kickstart][type] = profile

; Use dev git version with patch.
projects[commerce_kickstart][download][type] = git
projects[commerce_kickstart][download][branch] = 7.x-2.x
projects[commerce_kickstart][patch][] = \"patches/commerce_message_to_rc4.patch\"

And... breaking it down:

projects[drupal][type] = core signals that we're using Drupal core as the base install. Then, we're installing commerce_kickstart as a profile on top of that (projects[commerce_kickstart][type] = profile). When installing the profile, we specify git as the download type and the branch (7.x-2.x) that we are working on so that we get the correct version of the code that we worked on up above (which include's its Makefile). Finally, projects[commerce_kickstart][patch][] = \"patches/commerce_message_to_rc4.patch\" patches the distribution so that it downloads the -rc4 version of Commerce Message.

Now, build the project, if everything is correct, as the build goes by, you'll see the correct module being downloaded:

 >> commerce_authnet-7.x-1.1 downloaded.                             [ok]
 >> commerce_message-7.x-1.0-rc4 downloaded.                         [ok]
 >> commerce_physical cloned from                                    [ok]
http://git.drupal.org/project/commerce_physical.git.

And there we go. Now, push it up to your repository, and you're all set!

Continue reading...

Acquia Dev Desktop and the Drupal 7 test runner

Posted on: 2015-11-15 14:01:47

Recently, I tried to run some tests locally and the test runner kept silently failing. Ultimately, it was just giving up during bootstrap. The problem was eventually traced to Acquia's frustrating modification of the settings.php file; it only loads when $_SERVER['DEVDESKTOP_DRUPAL_SETTINGS_DIR'] is defined.

So in order to make it run, you'll need to:

  1. Define DEVDESKTOP_DRUPAL_SETTINGS_DIR in your CLI environment or:
  2. Modify run-tests.sh to populate that value in $_SERVER before bootstrapping Drupal:
$_SERVER['HTTP_USER_AGENT'] = 'Drupal command line'; $_SERVER['DEVDESKTOP_DRUPAL_SETTINGS_DIR'] = '/Users/myusername/.acquia/DevDesktop/DrupalSettings';

Then the test runner will actually do something useful.

Continue reading...

Technological pendulums

Posted on: 2015-11-09 06:53:47

I believe the future of technology is very much a return to simplicity that it seems like every generation or two we end up harkening back to. Modernity, for all of its marvels, feels like it is teetering on collapse. Personally, I see this in all over our society which can't seem to make up it's mind on what it wants. And if modern society could be defined by anything at this time, it'd be by a form of self-opposing delusion. People want security guaranteed by the government and also personal privacy. People want full personal autonomy to live their life as they see fit yet and yet feel obliged to force other's hands using the government when they find it hard to do so. We want the government to be a club for our cause yet so many forget the truth source and purpose of that government.

As it is with society, so also with technology with which society is so intertwined. We want blazing fast, ubiquitous, uninterrupted service but we want it delivered to us without any of the hard work which is required to build and maintain those services. And when a company like AT&T, Time Warner, or Grande Communications provides those services, someone will inevitably complain and emphatically declare what they want and why they are right and why they, the customer, is always right. I suppose we do truly live in an age of consumerism—where the customer is always right. And guess what? We are all customers now.

The pendulum has swung away from the BBSes of old: where groups of individuals combined their efforts to create autonomous, distributed, and personal networks of systems that were capable of transferring email across the world before the internet was in every home, so now it beckons to swing back the other direction. Yes, the pendulum is now seemingly at the very opposite of end of its swing. Where we are now is in an age of consumer demanded centralization: give me one store, one medium, one device that does everything. If it stops working or breaks, I'll throw it away and find another. And if I want it to continue to work, I'll pay exorbitant sums so that someone else can take care of it.

And what do we get for this? Little (if any) privacy. Being at the whim of masked men who wield digital armies and can take down your business for seemingly any reason.

Continue reading...

All code (and coding) is moral

Posted on: 2015-10-19 09:53:02

So I was reading through some blogs this weekend and came across an article about VW on the Clean Code blog. It's a short post and I suppose if you wanted a summary blurb, it would be this:

I think that argument is even more asinine than Michael Horn's. They knew. And if they didn't know, they should have known. They had a responsibility to know.

All too often, we tend to separate the code we write from what it does. In writing open-source Drupal modules, it might be very easy to try to say that there is a certain neutrality about what we do. Take for instance, one of my lowly modules Permission Report. All this module does it take existing information and display it to the user. It doesn't modify any values. And you could say that what it doesn't isn't good or bad—that it's morally neutral.

However, if something were wrong with my program, people would say something. If it were hiding certain roles or providing bad information, it could be an innocent mistake or it could be something malicious. But it would be flawed. The code itself would be bad. And we are no longer in neutral territory. If the code doesn't get changed, the code will be marked as such and it will eventually be replaced or forgotten by the community.

My point is, we don't do this for code that is "morally neutral." All code has some moral capacity in it. This parallels tangible objects such as cars, knives, and baseball bats which have a particular purpose but can be wielded in negligent or malicious ways. Likewise, open source code projects that have modules can be likewise wielded in ways that might align with or otherwise diverge from what we as individuals consider to be good, right, or true.

Now, for a module in a particular open source project that does a particular purpose: sending emails or handling a transaction, it could be used in a project that ultimately disagrees with our own worldview. However, the module itself with it's general quality, tests, and other functionality might be considered morally good, but the resulting use of it might be considered likewise to be morally wrong. But the point is that we didn't write the resulting use, we wrote the intended use and someone else wrote the final moral component. That doesn't change the fact that what we wrote was morally good, just that someone took something good and misused it. There is a difference between creating something good and having it's usage corrupted by circumstances and crafting the corrupting circumstances.

Circling back to the VW article, I'd like to make two points, then:

  1. As a programmer, we have a right—perhaps even a responsibility—to understand what the purpose is for what we are building. I think this is clear from what the author is saying. I would agree with this statement.
  2. Therefore, as a programmer, we have a right to decline work which we personally disagree with. While not stated explicitly, if the argument is that a programmer can and should be held responsible for code they wrote, then they should have the ability to decline to do so on the basis of legal or personal moral dissonance.

Programming, then, is a moral activity and should be treated as such by all who engage in it. Are we ready for this discussion?

Continue reading...