I had the pleasure of presenting at a recent Charlotte Drupal User Group meetup. The topic was all about selecting modules for a project and how to contribute back to the community. Below is my slide deck:

Creative Commons image courtesy of Ryan Vaarsi on Flickr

Recently, I realized that I learn a lot of new things for my vocation and general life experience, but I don't recognize and appreciate those learning moments. I noticed that days would pass and I couldn't remember what I learned. I am sure we all learn things every day, but much of those experiences are passive learning. While passive learning is a natural part of living, I want to have some planned and active learning in my life. Also, I want my study and learning to be multi-discipled.

There is no doubt that Drush is a magical tool in the Drupal community. Two very useful tools in the Drush "Swiss Army Knife" include drush sql-sync and drush core-rsync. These tools allow copying databases and files between Drupal instances.

If you need to have access to run Drush commands on a production server or via a Drush alias for a production server, policy.drush.inc can help prevent some devastating mistakes. Accidentally overwriting production databases and files can impact you and your clients negatively. The Github gist below shows how the built-in Drush policy functionality can prevent sql-sync and core-rsync from running against any Drupal instance that has a destination with prod in the name. This works for Drush aliases too.