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
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.
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.
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?
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.
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:
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.
