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.
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.
As a long time maintainer of the brewStack project, I have been spending time evaluating better ways to develop Drupal projects locally. Using VM based tools is a huge win because if you mess up a system configuration or setup, you can just throw away the VM and and start over. brewStack has been a great toolset, but you are altering your local Macs setup. Using Vagrant makes that much easier since you don't have to maintain VM snapshots or backups.
Last Saturday (February 21st, 2015), thirty-five Drupalers joined together at Classic Graphics for the sencond annual Charlotte Drupal Drive-in. The day was full of presentations, BOFs, and general chatting about Drupal and related web technologies.
The day-long, un-conference-style event was the brainchild of Thomas Lattimore. After CharDUG wasn't able to pull together the human resources to repeat the success of DrupalCamp Charlotte 2012, Thomas mentioned that he had an idea. Since he knew organizers had limited time to commit to planning and he wanted to host an un-conference-style event, allowing for simpler planning than a full-blown Drupal camp. You can learn more about his concept on the DruaplEasy Podcast.