Public

We (the Drupal community) cannot expect webchick to look even once at anything that isn't truly needed for D7's release at this point.

But i think we cannot tell exportables and other developer experience issues to go to hell for the next year or three either.

"About Agaric Design Collective"

Related links:
http://data.agaric.com/agaric-design-collective-profiled-academic-paper-snapshot-local-business-start

As root:
aptitude
Find drush under PHP.

At the bottom of the information about the drush package, there's an i that means installed next to 2.0 and a p that means no packages or config files or anything are present next to drush 3.3.

Type + when the drush 3.3 line is highlighted.

Then type g to upgrade (twice, first it takes us to a confirmation page).

Note: On Agaric's servers the package list is updated daily by a cron job, but updating the package list can be invoked by hitting u if necessary.

Castaways from the writing process:

Of course we should have an API or three. We know Jeff Eaton would stick APIs in a novelty module called Eldorado Superfly. No, actually, he didn't. From this we can learn that if our module is simple enough and uses enough of Drupal's APIs, it doesn't need to create its own.

[Eaton] drawing on his experience with VotingAPI, which, we might note, puts API right in the name of the module, and if that doesn't mean something, what does?

Changed our front-page mission statement from this:

Agaric uses the power of open source free software, the internet, and people to build sites that give control to our clients and their communities. Our founding principles include the goal of helping all people gain the most power possible over their own lives.

Please look around and learn how we can help you, and don't hesitate to contact us.

To this, which is mostly what we came up with a while ago:

for f in *;do mv $f ${f/test/prod};done

An alternate way to using a rename command, rename 's/dgd7_tip/remarkup/' * (from http://definitivedrupal.org/node/90/ )

In figuring out what changed in a theme's files (an incorrectly made subtheme; instead of overriding the base themes stylesheets, changes should have gone into its own files with different names), these commands were useful.

diff -uP themes/bartik/css/colors.css sites/default/themes/dgd7theme/css/style.css > theme.diff
git log --cc sites/default/themes/dgd7theme/css/style.css > log.diff

Kept running them for the three different files, and reloading theme.diff and log.diff in gvim to see the changes. Quite convenient.