Feeds (http://drupal.org/project/feeds) is a very popular module. From the project page, we get a nice description of the module:

Import or aggregate data as nodes, users, taxonomy terms or simple database records.

The basic idea is that you throw a csv file to it and it creates drupal content. As simple as that. The input format can be more than just a csv, check the project page for more details.

We can use the feeds api http://drupalcode.org/project/feeds.git/blob/HEAD:/feeds.api.php if we want more functionality than the standard.
I am going to describe 3 different uses of the the feeds api:

1. Perform an operation after a feed source has been parsed, before it will be processed
2. Perform pre-save operations
3. Add additional target options to the mapping form

I clearly remember the moment of excitement and joy couple of years ago when I discovered drush. Interacting with drupal from the command line? Wow! This was definitely something new to me, never seen it before in any cms.
Digging more, I discovered the wp-cli for the wordpress, but it seems that this in no way as mature as drush.

I use drush on a daily basis. For simple tasks such as clearing the caches or updating a feature to more complex stuff like in a deployment process or as an interactive php shell.

As with drupal, drush can also be extended. It is just a matter of writing the proper hook in the proper file. It is really simple and everyone can write their own drush commands.

As an example, I am going to show you how you to trigger a node save.

Setting up an apache vhost is a boring task. This is why most of the times, I use the h*tp://localhost/project subdirectory for my development work.

This is perfectly ok for most cases, however in some occasions you may wish to create a virtual host so that your project is accessible like: h*tp://project

To do this, you need to create a file in the the sites-available directory of your apache instance, set up a link in the sites-enabled directory, add an entry in the /etc/hosts file and finally restart apache.
Too much work. Fortunately we can automate it:

Create a template file (you can copy from an old project) in the sites-available directory. Replace every reference of your old project name and directory name with 'TEMPLATE'. Name this template file also 'TEMPLATE'
Then, create a shell script and add the following lines:

Features is a must have tool for deploying drupal sites. Features can be used for storing the website configuration in files, instead of the database. It can for example allow you to store a view in a file. You can then commit this code to your repo as usual.
Must of the site's configuration is stored in variables. Features, when used with strongarm, can be used to also export those variables from your staging env to your production. You can always find the name of the variable, by inspecting the html code. I use another trick to easily locate the variable name:

You can use

to get the value of variable. For example,

will return 1 or 0, depending on the value of the caching parameter set in admin/config/development/performance. If you dont know exactly the name of the variable, you can for example do a