When I beta-tested this talk with an IBM audience, I realized that there was no way in heck I could fit all the generally useful tips I wanted to share into the session, much less go into the joys of Eclipse, vi, or Emacs. (Especially Emacs. I could spend hours sharing what I’ve learned about Emacs.) Besides, editor choice is such a personal thing. So I’m not going to try to braindump all the cool things you can do with your development environment. Instead, find me at DrupalCon 2009 and pick my brain.

In the meantime, here are some tips that most people might find useful.

1. Meta tips
2. Browser tips and plugins
3. Drupal modules
4. Source code and configuration management
5. Automation and regression testing

Meta tips

1. Be lazy.

We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.

Larry Wall, Programming Perl (1st edition), Oreilly and Associates

Minimize your total effort and the total effort of your team. Learn more so that you spend less time looking. It’s amazing how much of a pay-off you can get from an hour or two just flipping through the Drupal API or the lists of Drupal modules – you’ll get a sense of where things are and what they’re called, and you’ll spend less time reinventing the wheel too. If you can invest thirty minutes in building a tool that’ll save you ten hours of work over the course of the project, do it.

2. Learn from others.

Join a users’ group. Read the Drupal forums. Hang out in #drupal, #drupal-support, and other channels on irc.freenode.net. You’ll learn so much from other people’s questions and answers, and even their approaches for figuring out what’s going on. And you’ll learn quite a lot by helping other people, too.

3. Know your tools inside out.

Read the documentation for your editor and development environment. Read the Drupal handbook and the API. Read the source code, even. Practice your editor’s shortcuts until they’ve been burned into your brain. Know your tools inside out, because they will save you lots of time and effort.

4. Know what’s out there.

One of Drupal’s strengths is the sheer number of third-party packages out there that you can just drop in and customize. Keep an eye out for interesting things. Browse through the available modules or view all the modules in a category. Subscribe to the Drupal Modules news feed in order to find out about new releases. Subscribe to Planet Drupal for interesting blogs. You’ll get lots of inspiration, too.

5. Practice relentless improvement.

At least once a week, invest some time in thinking about about what you’re doing and one small way you could do it even more effectively. Lather, rinse, repeat. As you incorporate more of these improvements into the way you work, you’ll free up more time and energy to work even better. Share your improvements with your coworkers or on your blog for even more benefit.

Browser tips and plugins

These tips are for Mozilla Firefox, because that’s what I use. =)

6. Firebug

Firebug: http://getfirebug.com/

Probably the single most useful extension for web development. I love how you can examine your webpage structure and even change styles or HTML elements on the fly. The Javascript console is really handy for testing JQuery statements and other scripts.

7. firefox -ProfileManager -no-remote

This is how you start a separate session of Firefox, so you can test your site using, say, an admin account and a regular user account at the same time. Bonus: you can set up a test profile with very few add-ons, so that your add-ons don’t interfere with the site you’re testing.

Other ways to accomplish this: run a separate browser, or use the Devel module to switch back and forth. Not as convenient, though.

8. Tamper Data

Tamper Data: https://addons.mozilla.org/en-US/firefox/addon/966

The Tamper Data module is handy when you’re debugging form submits or page redirects, because you can step through the requests or change any of the submitted values.

Alternative: The Devel module for Drupal lets you intercept redirects too.

9. iMacros or another recorder

iMacros: https://addons.mozilla.org/en-US/firefox/addon/3863

Record and automate repetitive browser-based tasks or tests. Really handy for testing those pages where you have to log in, click on this link, click on that link, set this text field, and so on.

10. Drupal for Firebug

Drupal for Firebug: https://addons.mozilla.org/en-US/firefox/addon/8370

Comes in two parts: a Firefox add-on and a Drupal module. This extends Firebug to give you all sorts of Drupal-related goodness, such as a message log, variable dumps for users, nodes, and forms, and data about your views. Reduces the need to insert var_dump into random parts of your code to figure out what’s going on.

Drupal modules

11. Admin Menu

admin_menu: http://drupal.org/project/admin_menu

One of the first modules I install on a Drupal project, this module adds a much more usable dynamic administration menu along the top of the page.

12. Devel

devel: http://drupal.org/project/devel

Lots of goodies for developers and themers. I particularly like being able to view all the SQL queries run on the page, with slow queries highlighted. You may also want to set the SMTP library to Devel during testing, so that you can test e-mail without actually sending e-mail.

13. SimpleTest

simpletest: http://drupal.org/project/simpletest

You can use SimpleTest to test your system both at the source code level and at the web page level – it includes a simulated browser, so you can send GET and POST requests and test whether the results contain text or things like that. Tests are tremendously handy for improving your source code quality. You can also use this to generate lots of test data – just write a test case that creates the test data, and then call the tests you want.

14. Login Toboggan

logintoboggan: http://drupal.org/project/logintoboggan

Configure it to display a login form on every page. You’ll find this helpful when you’re testing various parts of your site, reloading the database from the backup, or generally doing things that involve logins and sessions. You might like it so much you’ll leave it on all the time. =)

15. Xdebug

Xdebug: http://www.xdebug.org/

Not a Drupal module, but a very useful extension for PHP. Use either this or the Zend debugger to pretty-print nice stack traces and variables, or even step through your code. Your debugging life will get so much easier when you figure out how to integrate this with your development environment.

Source code and configuration management

Tip 0: Use a source code control system. If you don’t, you’re inviting disaster. Trust me, you _really_ want to be able to revert to code that’s known to work.

16. Check in your entire Drupal source tree.

Don’t get tempted to just check in the sites/ directory. You might need to touch others, you might need to upgrade core… Anyway, things could get messy. Just check it all in at the beginning, and your development and deployment will be easier.

17. Organize your source code.

Use different site subdirectories for multiple environments, and use subdirectories to organize your modules. This can help you keep your testing modules separate.

I usually work with a local development environment (ex: local.example.com), a testing environment (ex: qa.example.com), and a production environment (ex: example.com). All of the modules that should be available to all those environments go in sites/all/modules. Sometimes I find it handy to put open source modules in sites/all/modules/oss/ and custom modules in sites/all/modules/custom, or another project-specific directory. Development modules that should never ever end up on the production server (such as simpletest and drush) go into sites/local.example.com/modules, and I use symlinks to make the modules available in other testing environments as well.

18. Check in clean source for third-party modules.

With Drupal’s hook and theme system, you can generally get away without directly modifying the source code of well-written modules. However, modules might not have the hooks you want. Before you make any modifications to third-party source code, make sure that a clean, unmodified copy is checked into your source tree. This makes it easier to upgrade the module later on: just get the difference between the current version and the last clean version, install the new version, and reapply the differences (correcting the patch when necessary). To be safe, commit the source code as soon as you unpack the module.

If you started with an already-modified version, don’t worry. It’s not impossible to correct, just tedious. Get the difference between the modified source code and the clean source code, commit the clean source code, and then apply those differences.

19. Test all upgrades against a copy of the production database.

This is related to configuration and change management for a live site. When developing improvements to a site that’s already in production, you’ll often find yourself needing to set variables, enable new modules, and make other changes. Resist the temptation to make these changes by hand as part of a manual upgrade process. You don’t want to do that. You can experiment with making changes through the web-based interface for sure, but any behavior-related changes should (and can!) be written as update functions in the relevant .install files. This allows you to test the upgrades against a copy of the production database as part of your quality assurance process.

CAVEAT: install functions are run in a certain order: alphabetically by module, and then numerically by update number. Keep that order in mind when writing update functions that interact with other modules that also have updates.

For more about this, come to the panel on staging and deployment at DrupalCon 2009 – I’ll be there too!

20. Manage your source code branches and track changes that need to be merged.

Once your website is in production, you’ll find yourself working on bugfixes for the current site and new features for the next version. Save yourself pain and suffering by learning how to use your source code management system’s branching commands to maintain at least two branches of the source code tree – one for the development version, and one for the current released versions. Also look for tools to help you remember which changes you’ve applied to both branches. For example, the svnmerge tool is handy for managing Subversion tries. That way, you can fix bugs on the release branch and merge them into the development branch, so that the next version won’t have those bugs either.

Automation and regression testing

21. Use build tools

You run lots of different commands as part of development. Refresh the database from the backup. Clear the cache. Enable development modules. Connect to the database. Instead of trying to remember or re-type all those commands, use a build tool like GNU Make or Apache Ant to simplify your work. For example, I have my Makefile set up so that no matter what project I’m currently working on or environment I’m currently working in, the following commands pick up project-specific settings and do the right thing:

make mysql	connect to the database
make backup	make a copy of the database
make backup-partial	make a partial copy of the database, omitting accesslog data and other unnecessary information
make restore	restore the database from the backup
make dev-restore	restore the database from the backup, and enable all the development modules
make clearcache	restore the database from the backup
make tags	restore the database from the backup
make doc	restore the database from the backup
make test	run all my project-specific tests

You’ll enjoy not having to remember the command to type.

22. Learn or make tools to save yourself work.

This is an application of tip #1. A little scripting goes a long way. Learn how to write shell scripts and you can save yourself a lot of repetitive work. For example, my team members regularly need to deploy revisions of our source code to the QA testing server. In my team, I’m the most comfortable with Linux. Instead of doing all the deployments myself, I spent thirty minutes writing a script that lets any of the team members start a build. (For a while, I even integrated all the unit tests into it!). The whole system is a bubble-gum-and-string contraption involving PHP, a shell script, a Makefile, and SSH, but it works.

23. Make the most of the Drupal shell (drush)

drush: http://drupal.org/project/drush

Drush totally rocks. Drush makes it easy to run Simpletest tests, SQL queries, even evaluate PHP statements within the Drupal context. I modified mine to make it easy to upgrade modules, too, which means that I can restore from a backup of the production database and run all the update functions within a minute. Learn how to use the different commands built into Drush, and add your own. You can save a lot of mouse clicks and time that way, and you’ll find it easier to automate things (including testing!) and integrate that into your workflow.

24. SimpleTest

Introduced this previously (#13), but it’s well worth repeating. If you implement other tips (such as #19: check all upgrades against a copy of the production database), your tests will become incredibly useful. Write lots of tests using SimpleTest and associate them with a group. Restore your copy of the database using the production backup. Run all of your updates. Use Drush to run the group of your project-related tests, or individual tests. A good test doesn’t display anything if the test passes. If everything passes, hooray! If a test has broken, find out what’s wrong–the code or the test–and fix it. Lather, rinse, repeat.

25. … What’s your favorite tip?

Leave it in the comments below, or share it with everyone during the DrupalCon 2009 session on Totally Rocking Your Development Environment, from 11:30 – 12:30 on on March 4 in the Trellon Room.

Can you see why I’m going to have a hard time fitting all of that into the 60 minutes I have? ;) Particularly if I’m showing things. And I really don’t want to talk _all_ the time, because I’d love to hear people’s tips too. Come and join us on a whirlwind tour. Ask questions. Share your tips. It’ll be fun. =)

Related sessions you might be interested in:

Drupal Patterns: Managing and Automating Site Configurations: ChrisBryant, March 5, 3:00-4:00
Staging and Deployment – A Panel Discussion: Greg Dunlap, Kathleen Murtagh, Shaun Haber, and me: March 5, 5:15-6:30
Drush, Command Line Drupal Productivity: Moshe Weitzman and Owen Barton, March 5, 5:15-5:45  (conflict!)
Drupal Process Management: Drew Gorton, March 6, 9:00-10:00