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:
I use drush aliases between Drupal VM and Drupal hosting services quite a bit. It was great to learn that drush site-set allows me to set the alias to use for the current session, so I don't have to type the alias name over and over again. For instance, I can set an alias like this: $ drush site-set @drupalvm.drupal8.dev, allowing me to check the status of the site on the Drupal VM with $ drush status.
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.
Many developers use Vagrant to maintain development environments. Some may not realize that there is a Vagrant plugin architecture that can extended functionality. Plugins provide a wide range of functionality including, new commands, low level Vagrant interaction with action hooks, new providers to replace VirtualBox, and extended host and guest capabilities.
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.