A Content type (or rather node type) is a Drupal construct and is relatively recent, making it partially into core in D6 and almost fully into D7.

Should we build a client site in PHP, Wordpress, Zend, Cake, .Net, Symphony, or most other frameworks then the phrase ‘content type’ (particularly what it means in Drupal) will not apply or at-least mean something slightly different.

In Drupal 7 and soon in Drupal 8, what content types used to be has evolved and changed. There are also other modules and other techniques which can and sometimes should be used to build the functionality which used to only be available from content types.

Using direct system specific terms like “content types” when discussing client functional needs is problematic in that it is only really relevant to Drupal and its meaning and usage can change in Drupal.

We should communicate with clients as much as possible at the functionality level and not the system level. Whenever a client has a little system level knowledge they may try to move conversation or even decision making down into the system.

For their sake, stop them. Move the conversation back up into the area of functionality.

Functional specifications provide the list of needs/wants that we must meet for the client.  Functional specifications should ALWAYS be technology agnostic.  System design choices can change over time, change with tool selection, and are often best made at the time of actual development.

So, what does it look like to talk functional specs instead of system specs?  Surprisingly, it’s almost the same thing; but different by one degree.  (My father used to talk about flying and how being off by one degree for too long will land one in the Mojave rather than Palm Springs.  Not good.)

Read More »

I created this mockup to communicate with clients and other dev teams the general dev to production process I set up for most client sites.  I've used the mockup a few times and it has been helpful.  

Remember, this is a general overview and most projects have specific differences in the build system depending on the project needs and the make-up of the development team.

I have included downloads of it for you.  Formats include Screen Optimized & Print Optimized PDFs, a PNG, and a zip file with the Balsamiq Mockup source file. 

In this short screencast I'll show you how to use Drupal 7's built-in Ajax Framework to dynamically update web page content with new data from the server; all without a page reload.

You can view the screencast here: https://vimeo.com/39479686 And get the code from github here:

https://github.com/seanbuscay/drupal-ajax-demo

I have pasted the script for the video below to give you an idea of what's in the content.

Read More »

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

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 »

After reading the book version of this article, Big Macs vs. The Naked Chef by Joel Spolsky I wrote down a few thoughts on the difference between knowledge management and creating a procedures/rules book.  

I often examine processes to improve productivity. On my teams I push for documenting solutions to record and share with other team members. However, it’s important to understand that documenting process and procedure alone does not equal the spread of knowledge or an increase in expertise within your team or organization.

As any phone call to Dell tech support will show you, the act of following a tech manual step by step will usually not get your computer fixed. Procedures are nothing without very smart and experienced people working for you to find a solution. It’s also the very smart and experienced who don’t really use a procedures manual.

As Joel Spolsky writes in his “Big Macs vs. The Naked Chef” post:

1. Some things need talent to do really well.

2. It's hard to scale talent.

3. One way people try to scale talent is by having the talent create rules for the untalented to follow.

4. The quality of the resulting product is very low.

So what do we use in our teams and organizations instead of rules and regulations?

1. We hire very smart and experienced people
2. We implement a knowledge management system

Knowledge management helps when you have a team of experts or hire really smart people, instead of just hiring people to follow a rules book.

Knowledge management means that geniuses within your company may apply different and varied solutions instead of a single cookie cutter one, as long as:

Read More »