My wife is known by myself and friends as someone who’s excellent at managing projects.

Her ability to start from nothing but a goal and produce real results with many moving parts always impresses me.

Her secret is that she approaches projects with the perspective and skills she developed in theatre while producing and directing stage plays in college and later managing a cast of a hundred in professional theatre.

I wanted to learn more about her process so I asked her to describe to me how to produce and direct a stage play.

The following is what this web developer learned from the stage play director, and how to apply  her methods to any good development process.

Directing a Stage Play (In Brief)

Read the script over four or five times

Before anything, become very familiar with the script until you know it inside and out.

Start at act one - scene one

1. Work through the script and make notes on what’s needed to produce each scene.
2. Research parts of the script as needed, such as time period or subject matter.
3. Define elements such as blocking, set design, ect.

Rehearse early

After casting, begin rehearsals early.

1. Start with a sit down to do read-throughs and discuss the characters.
2. Later progress to the stage.
3. Refine elements of each scene over time.
4. Provide notes to actors on specific changes or areas for improvement.

Meet separately with other departments/crew

Schedule miscellaneous meetings and discussions with set designers, sound, costume design, and any other parties that support the overall production.

Communicate the vision for the play and get their feedback on ways to make it happen.

Read More »

People often ask me about the process I use to develop large scale web applications.

The following is a brief introduction (high-level overview) which I use to begin to explain how it’s done. There are links at the bottom of this post to begin to explore the process in more detail.

The discovery processes and development plans will always be customized to clients’ individual needs. However, the following process is one that is very typical for many clients. This is not just my method. It’s a common process for many development shops and consultants.

Discovery

Project kickoff usually begins with a Control Memo (a master project document), which serves as a communication tool to explore a client’s needs for the project. I use this document as a discussion point with clients to:

1. Discover more about their project’s business, marketing and technical needs.

2. Record what I think we all already know and get clarification on what we might have missed.

3. Be in a position where we have collected enough information to provide a client’s team with the following:

   1. Functional Specifications
   2. Technical Specifications
   3. Milestones and Schedule

Development

After technical discovery, in development I use a modified version of the Scrum development methodology, one of the classes of Agile development.

The requirements documents, final mock-ups, and design elements constitute the Product Backlog in the Scrum process. The Product backlog is the culmination and summary of needs defined in the:

1. Functional Specifications
2. Technical Specifications
3. Milestones
4. Features list
5. List of mock-ups and design elements

All technical documents are kept under version control.

Main development typically takes place across periods of 30-day code sprints.

Read More »

Just created an 1140px Drupal Zen Theme Based on cssgrid.net.

Fork it or download it here: https://github.com/seanbuscay/chi

Tell me if you have any issues with it.

I recently returned to using a standing desk. I purchased one which allows you to sit and stand from http://www.geekdesk.com/ .  I love it.  

See the video below

Here are a couple of the NY Times articles which inspired me to return to a standing desk:

Can’t Stand to Sit Too Long? There’s a Desk for That

Stand Up While You Read This!

And here's a nice article on how to build a standing desk with inexpensive parts from Ikea:

http://www.ikeahackers.net/2011/01/wide-standing-desk.html

Install the Quickstart Development Environment

This tutorial covers building your own development server with a fresh Ubuntu install and the shell scripts from the Quickstart Drupal Development Environment. See: http://drupal.org/project/quickstart

The Quickstart project provides a pre-made virtual box which you can download with links from the project’s page. If you just want to start with the virtual box, then you can skip to the next section which covers adding the Hudson server.

Let's get started.

On your Ubuntu machine (or virtual machine) open a command line (Applications->Accessories->Terminal) and check out the Quickstart files from CVS. Type or paste the following commands:

$ sudo aptitude -y install cvs

$ cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d quickstart contributions/modules/Quickstart

The above commands pull the Quickstart project files to your Ubuntu box.

Read More »

The following are notes to my developers which I share now for the benefit of clients and dev teams who are curious how an enterprise build system may be set up.

Understanding the repo structure

The Mercurial repos in Kiln are structured as follows:

Project->Environment Stack [repo group] -> Repos (code, dbsnaps, [others])

Project

Projects are usually titled with the project number preceded by the letter “p”. The letter “p” is short for “project” and is only there because Kiln (and other repos) will not accept just numbers for a project title.

In a few cases, like for the RRA website, the project will have a string (text) name instead of a project number. This is because multiple concurrent projects are running for the RRA web site and it makes sense to keep the work under one project. In this case the project is titled, “prra”. Note the letters are all lower case.

Environment Stack

The default stack is called, “main”. This is the dev/integration environment on the cloud dev server.

Other stacks may include qa, loadtesting, production, or anything else needed. These stacks may exist on the dev server, or other servers, including the production server.

Repos

Change Note: This section notes our change from the practice of separating Drupal code into three repos. We have found the benefits of managing all code in one repo outweighs longer initial pull or push times. The older version of this section remains at the end of this doc for historical purposes.

code

This repo combines the previous three repos (drupalcore, sites, and sitesall) into one. This repo contains all code to run the client site, as well as special files build scripts which can modify the build process at runtime.

dbsnaps

This repo may contain multiple database snapshots (sql files). The one file titled, “db.sql” is the primary source file for site builds.

Here is a typical scenario:

1. We start a new dev project (new or existing site)

a. We receive an sql file which is a full sql dump of the site database (hopefully with the cache and watchdog tables truncated).

b. This file goes into the dbsnaps repo and will be titled, “db.sql”.

c. We should all build off this version controlled file.

d. Auto builds will also take place off this file.

2. We may decide to test some changes to the branch we are working on.

a. These changes could involve changes to the data structure.

b. To help us roll back quickly, or to make a diff of the changes we made, we can use the backup_and_migrate module to output a snapshot before the changes and then output a snapshot after these changes.

c. These files may be checked into the repo for safe keeping and may be used to create a diff file/patch to look for exactly what changes were made to what tables.

Remember, these sql files are not the primary source for the builds, and db.sql will overwrite the db on the next build.

3. Actual db changes should be made in code via views export, features, chaos tools, and sql statements in hook_update functions.

How to trigger a build

To trigger a build, push a change to the repo.

That’s it.

If you’d like to know what happens after that, read on.

The Kiln/HG web hook will trigger a call to the dispatcher script on our dev server.

1. The call to the dispatcher includes a token to authenticate its source

2. and a json payload containing information about the check in.

The dispatcher will then:

1. authenticate the source of the call and record the call in its log file

2. upon authentication prepare the secure call to Hudson to trigger the build with parameters parsed and passed from the json payload

3. ignore a call to build on the production server as these are manually controlled via Hudson

4. perform miscellaneous tasks such as emailing notifications and adding a record of the dispatch to our intranet

Once Hudson receives the call to start a build, the following happens:

1. The repo is initially cloned if it does not exist on the dev server, or pulled from then updated with a hg update --clean.

2. A build ini file is searched for in the updated repo and if found parsed for variables.

3. A prebuild sh script is searched for in the updated repo and if found ran.

4. The project is then build with an import of the dbsnap and a symlink from the web root to the code repo.

5. A build sh script is searched for in the updated repo and if found ran.

6. A vhost file is added to /etc/apache2/sites-available/ in Apache, enabled, and Apache is reloaded.

7. A postbuild sh script is searched for in the updated repo and if found ran.

8. The following Drush and shell commands are ran in downstream jobs and the results recorded in the Hudson console and actions are triggered by results.

Miscellaneous cleanup and logging

a. drush --yes pm-enable dblog

b. drush --yes watchdog-delete all

c. drush --yes cache-clear all

d. drush --yes updatedb

e. drush --yes cron

f. drush --yes pm-refresh

g. drush --yes status

h. drush --yes watchdog-show

i. drush --yes pm-list

Run Coder Module from Drush

j. drush --yes dl coder-6.x-2.x-dev

k. drush --yes pm-enable coder

l. drush --yes coder contrib critical

Patch and run Simpletests

m. drush --yes dl simpletest-6.x-2.x-dev

n. patch -f -p0 < ${WWWROOT}${STACK}${PROJECT}/sites/all/modules/simpletest/D6-core-simpletest.patch

o. wget http://drupal.org/files/issues/simpletest_run_on_a...

p. patch -f -p0 < ${WWWROOT}${STACK}${PROJECT}/sites/all/modules/simpletest/simpletest_run_on_any_profile_6.16_0.patch

q. cd ${WWWROOT}${STACK}${PROJECT}

r. drush --yes pm-enable simpletest

s. mv ${WWWROOT}${STACK}${PROJECT}/sites/all/modules/simpletest/run-tests.sh ${WWWROOT}${STACK}${PROJECT}/scripts

t. rm -rf ${WWWROOT}${STACK}${PROJECT}/scripts/tests/*.xml

u. /usr/bin/php ${WWWROOT}${STACK}${PROJECT}/scripts/run-tests.sh --url http://${DEVURL}/${STACK}${PROJECT} --all --color

Tools

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

2. Coder: http://drupal.org/project/coder

3. Simpletest: http://drupal.org/simpletest

Deprecated Section on Repos

We use four repos to break code into sets that are managed differently and/or updated at different frequencies. This separation of code into sets speeds up your most frequent pulls and pushes and our most frequent auto builds.

drupalcore

The “drupalcore” repo is updated least often. It should contain only core Drupal code and should be unchanged from the version in which it was downloaded from Drupal.org. For example: the Drupal 6.16 zip file. Sometimes we may receive client code which has Drupal core code modified. We should try to bring the client’s code back to core by moving any hacks on core into a custom module or theme function.

sites

The “sites” repo contains everything in the sites folder found in a normal Drupal setup, except the “sites/all” directory. Additionally, ff the web site uses “sites/default” as its Drupal site folder then this directory will contain the site’s assets.

For the auto build process, the “sites” directory will have an extra site folder to be used on the dev server. For example, if the project number is 957, then the sites directory will contain a folder called, “main957.seanbuscay.net”. In “main957.seanbuscay.net” there will be a settings.php file with the config info needed to run on the development server.

This repo is rarely changed. We may, from time to time, add files to it from the production server so we may see the latest images and assets while testing on the dev server. No primary code changes should take place here.

sitesall

The structure of this repo is a little different from the others. It starts off with just one immediate child directory called, “all”. This folder corresponds to the typical Drupal setup path of “[Drupal root]/sites/all”. Inside this “all” folder are all modules (custom or contrib.), themes, libraries, and features.

Typically, this is where we do most of our coding. Adding modules or writing custom modules. Customizing themes and creating new ones. This repo is updated most often.

Please note: In some cases, a module or theme should only be exposed to one site instance in a Drupal multisite setup. If this is the case, we can either do our dev work in this repo and then later move the modules or code to the site instance folder, or start off in that site instance folder in the “sites” repo. In this case the “sites” repo will become our most frequently updated repo.

dbsnaps

This repo may contain multiple database snapshots (sql files). The one file titled, “db.sql” is the primary source file for site builds.

Includes Upgrading Drupal Modules, Themes, and Site

I am a fan of check lists. They help simplify and improve the effectiveness of repetitive processes over time. The following is a recent check list I shared with a client as a summary of the process used to upgrade from Drupal 5 to Drupal 6. Please feel free to use it and add your own notes.

1. Together with client identify the list of key content and expected behaviors/displays. Includes any publishing/business logic.
• Should be approximately 30 or so check list items, with accompanying screenshots where appropriate.
• This will form the QA test script to confirm the quality of the upgrade and will be the list for acceptance testing.
2. Duplicate the site, code, db, and files into an upgrade branch on dev server.
3. Version control all code, db, view exports, ect. throughout the process
4. Confirm there are no custom hacks on Drupal core.
5. Run the upgrade process for Drupal Core.
6. Test
• All steps titled test include some automated testing as well as use of the coder module.
• I also just came across the deadwood module.
• Test steps also include running through the QA test script when appropriate.
• See links below.
7. Run the upgrade process on views, converting views to views 2
8. Test
9. Identify any custom hacks on contrib. modules.
10. Upgrade contrib. modules which have D6 versions
11. Test
12. Identify upgrade paths for non standard modules and those which do not have a d6 version
13. Code the upgrades and run them
14. Test (full developer review)
15. Client QA and site review/Bug fixing Cycle
16. Prepare deploy plan
17. Deploy the upgrade on production server
18. Client QA and site review/Server Configuration and Bug fixing Cycle
19. Client Acceptance testing (walking through the script), reporting and fixing issues cycle

Links About Upgrading Drupal

Converting 5.x modules to 6.x - http://drupal.org/node/114774

Updating Drupal Modules to D6 in Three Easy Steps - http://www.webmasterworld.com/content_management/3...

Coder Module - http://drupal.org/project/coder/

Deadwood - http://drupal.org/project/deadwood - http://boombatower.com/tools/deadwood

This post from 37 signals provides a nice understanding of estimates.

While contracting for the Tree House Agency last fall, I am very happy to have architected, project managed, and lead the development of the New House Democratic Website (http://dems.gov)

From: http://www.dems.gov/press/house-democratic-caucus-launches-new-website

The site features what Democrats are saying each day, by issue and about major legislation. For the first time, visitors will be able to easily find quotes from Members on the topics and legislation they care about most. The site also features major legislation passed by Democrats and summaries of upcoming bills. In addition, the public can find House Democrats’ official websites, YouTube channels, and Facebook pages using an interactive directory.

The new site allows the caucus to:

1. Aggregate content from congressional members (video, text, feeds, and other forms of media)

2. Share content with the public and reporters in a way that it easy to navigate

3. Provide multiple views for visitors to browse and search content by facets of interest

Of course we built it in Drupal for the public facing website because of its ability to present content to visitors in a variety of ways; with all the social networking tools of today’s websites and Drupal on the administrative end was the clear choice when it came to meeting the administrative and security needs of the Caucus.

Nice post on Smashing Magazine reminding us not to forget the small stuff in the new year: http://www.smashingmagazine.com/2010/01/23/dont-forget-the-small-stuff-this-year/ .  For example, did you change the copyright date on all your clients’ sites?

Here are two interesting client issues I had in after the New Year.

Expired Security Credentials

A client called to ask for help getting access to an old Content Management System they had for about four years.  The site just stopped allowing them to log in. Turned out to be the site was on a Windows Server which authenticated via the Windows User Groups.  After four years, the server reset the user account privileges. 

The lesson: Watch server configs and security accounts in the new year.  They often (correctly) expire after a certain period and this often occurs at the start of a new year.

CCK Date Fields Stopped Working

Here’s one for us Drupal CCK Date field users.

One of my clients has a content type which includes a publication date using a CCK Date field.  Suddenly, they could no longer save changes to nodes in this content type. 

This was the error message:

An illegal choice has been detected. Please contact the site administrator.

Here’s what happened:

The CCK Date field has a setting called, “Years back and forward.” 

Read More »

A friend just emailed me the following question:

As a Business to Business Company is it better to have your company blog hosted on the company website or should it be more indirect and hosted on wordpress or something like that. 

I am getting conflicting answers from my people and was wondering if you had any advice.

The following is my response back.  Hope this helps you as well.

In answer to your question about whether a B2B company should have their blog hosted on their website or on something external I'd look at the importance of the following:

1. Branding
2. Maintaining the technology
3. Lock-in
4. Reasons to not be on your main company site

Branding

To me, branding is the most important.  If your blog is a key part of your communications strategy then you should have full control over all the elements that show up on the blog:

This is not to say you can't use a service hosted off your current servers.  Just that the logo, design, content, domain, comments system, auto-emails, and even functionality should all reflect your brand.  I recommend the blog be on your company's main domain.  If it must be hosted somewhere else, then a sub domain can work.  The key is that you do not dilute your brand across multiple domains. 

Additionally there should be no third-party content that could show up on your blog without your direct control, such as advertising automatically shown by the blog network you may be hosted on.

Read More »

Totally loving this tool to not only have my info backed up in DropBox but to also have it synced between my Laptop and Desktop.

Right now I have junctions (and thus synced directories, data, and profiles) for:

1. Skype
2. Firefox
3. Chrome
4. Aptana (Eclipse)
5. Topstyle
6. CuteFTP
7. My sticky notes
8. My local web server, sites, and databases
9. Pidgin

My new favorite jquery tool for data table sorting and searching.

Excellent tool with as little or as much configuration as you'd need for most any project. Very slick.

Used this to commit horrible usability crimes at the client's request. Shame.