Project Flow & Tracker basic (non-UI) installation profile on GitHub - Status update for early-December 2010Tue, 2010-12-07 10:11 — victorkane
Project Flow & Tracker installation profile is now ready in basic, non-UI form at https://github.com/victorkane/ProjectFlowAndTracker/tree/6.x-1.0-alpha1 on the 6.x-1.0-alpha1 branch. Be sure to change to that branch after cloning the project or else before downloading the tarball. Instructions are on the README.md file for that branch.
The installation profile includes the following:
So, Drupal web app builders, Drupal 7.0 RC 1 Released. It's coming soon to a development environment near you! So, who can help dive right in? The very well written drupal.org announcement mentions the updating your modules and updating your themes pages and the Coder Upgrade module. But curling up with a good book would be nice too. So I was eager to review Drupal 7 First Look by Mark Noble in order to see if it could assist me in systematizing my own approach to becoming familiar with Drupal 7 and preparing myself for "the big shift" as a Drupal developer.
Towards a straight up Drupal development workflow for the working stiff – can't we all just follow industry standards?Fri, 2010-11-19 11:28 — victorkane
I need to write an installation profile for Project Flow and Tracker in order to publish it right on http://drupal.org so that it can be contributed to the community. My goal however is to avoid coming up with one of those monolithic install profiles whose drupal core or modules and themes you can never update on your own without breaking everything, whose functionality you have to take as is on an all or nothing basis, and which is generally speaking unmaintainable and has to be replaced en bloc (sometimes en bric) whenever there is a new release (i.e. erase everything, copy in the new release, run update.php...).
The promise of Contexts and Features driven development was that you got to develop incrementally with everything in code (modular, versionable, automatically buildable), then with the help of Drush Make and the Install Profile API you could make a modern installation profile which simply installs the features and their dependencies, and reverts them to make sure they are properly enabled. And that this cycle can be repeated transparently as the app evolves, as part of its development workflow.
But the reality is that features are the coolest thing in town, but once you knock on that mistress' door, you are imprisoned in her magic forever; and you don't wind up with reusable self-contained components for all your pains. In this article we are going to find out why that is and come to some conclusions as to what can be done about it (under the circumstances). I will present the problem and share conclusions as to how best practices can best be approximated in Drupal app development, and will illustrate conclusions I have come to as to the most sustainable method of creating an installation profile in the context of an ongoing application project.
I touched on this recently in Features driven development -- the nitty gritty and thoughts on the future of sustainable "in code" development, but now I want to systematize my ideas and figure out what to do about it.
The most important thing to consider is that Features as development workflow breaks a fundamental law in Software Developoment:
Software development law #1: there is no one-to-one relationship between use cases (features, functional requirements, user stories, etc.) and project configuration artifacts (modules, themes, menus, blocks, panels, settings, etc.). A single project artifact will serve as part of the implementation of many use cases; a single use case will be implemented in many project artifacts.
Project Flow & Tracker "Chicago" ready for basic use and download - Status update for mid-November 2010Wed, 2010-11-10 11:06 — victorkane
Now close to "Chicago" release candidate and more usable than ever, the Project Flow & Tracker project has been made public and promoted to front page so you can browse the read-only functionality. I believe browsing from business model to roles to user stories to constituent tasks and back again is the best way (in theory and in practice) to understand what has been achieved at this point.
Much greater usability has been achieved, which is something that will be receiving a great deal of attention as a jQuery based UI layer is implemented in the next phase.
Deploying content from a staging server to the live site is important: that's the first thing you learn when you actually start using a Drupal site with any significant traffic, that editing a live site with traffic is hopeless. A couple days ago I showed a simple example with two brand new sites (one staging, one in the role of "live"), installing the deployment module in order to have node operations and references carried out on the basis of a once-in-a-lifetime-assigned UUID rather than its arbitrary node id (the arbitrary nid assigned if you say export and import nodes using the otherwise excellent Node Export module). But what if you now realize that you need this after the site has already entered production? This article reports back upon attempting to do this with the literary workshop example published in my book, Leveraging Drupal.