RDINB Misc Goodies

[resplin]

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

RDINB

Bob Lewis on Project Management

Another observation about projects ... there is no such thing as project momentum. Projects don't want to get done. Their natural state is to slow down until other forces overtake them. Projects keep moving as long as we keep moving them. And this requires, I believe, the ability to see the end.

Childers is right on the money, and neither the reason nor the resolution is methodological.

Project management requires diplomacy, to balance the competing needs of different business managers and executives, no two of whom agree and all of whom have more political clout than the project manager. It requires frequent, deep communication with all of the employees who will be affected by the project's intended outcome and would be just as happy continuing to work as they have been. For all concerned, project failure would very probably be more convenient than success.

Project management also requires constant attention to the project team's emotional state and interpersonal interactions. Working on a project is more stressful, although less boring, than working on a job that involves doing the same work day in and day out, for at least two reasons:

First, when employees participate on a project, every day calls for creatively solving another new set of problems. That's more stressful than handling the same old same old.

And second, working on a project is like taking a long journey on foot. Intellectually, you know that if you can walk at a steady pace of 3 mph for 6 hours each day, then to reach a destination that's 1,000 miles away you'll be walking for less than two months.

Right. I'd take the first step and think, 'A thousand miles to go? I'll never make it!' No matter how many verses of One Thousand Bottles of Beer on the Wall I'd sing, the finish line wouldn't seem any closer. Giving up can seem like a very attractive alternative after a few thousand paces.

Project teams, like all organizations, are intensely human activities. For some unaccountable reason, many project management methodologies, business schools, and entire consulting practices ignore this simple, inescapable fact. They view the enterprise one dimensionally, as collections of processes, or cash flows, or value chains, knowable through reports, dashboards and scorecards.

Some project managers, IT managers, business managers and executives fall into this trap, mistaking reports for the state of the business. Presumably, when on vacation, they similarly mistake the map for the countryside.

The best know better. They know that before the processes, cash flows, and value chains, and the reports, dashboards and scorecards, the enterprise is an assemblage of men and women who expend time, effort and intelligence to help the organization succeed. They know who matters in it -- not just by title, but also from informal influence or because if they're hired away by a competitor the roof will fall in. They know that it is a complex network of human relationships and they carefully define their place in it.

Because these executives know better, they become adept at building their own personal networks -- PunditSpeak for developing friendships throughout the company. That means that while the rest of the executives look at sales and margin reports, express concern that the numbers look bad, and argue with each other about what to do about it, the best executives know that the delivery teams the company is putting in front of clients have too many insufficiently competent members, resulting in re-work, make-goods, and other margin- and reputation-killers. They know because they talk with the sales force and account managers all the time, listening instead of challenging and 'holding them accountable.'

Their reputation throughout the company is based on large numbers of employees at all levels knowing, respecting and trusting them. So when the time comes to fix a problem, they've already established the credibility they need to be persuasive about the reality of the problem and the necessity of the solution.

The best business executives know this. The best project managers know it too. They have to. Otherwise they wouldn't be the best project managers.

Heck, they wouldn't even be adequate ones.

SVN Tip by Danny

Subversion stores it's configuration files in {{%USERPROFILE%\Application Data\Subversion\}} in Windows (where {{%USERPROFILE%}} defaults to {{C:\Documents and Settings%USERNAME%}}) or {{\~/.subversion}} in Linux/Cygwin (where ~ defaults to your user's home directory). The only configuration file is named {{config}}.
{tip:title=Synchronize Windows and Cygwin Subversion Configurations!}
If you're clever, you can make sure all Windows-based Subversion access (such as your IDE or a tool like TortoiseSVN) uses the same Subversion configuration and settings directory as your Cygwin command line.

1. Open up a Cygwin (bash) shell.
   
2. Remove your {{\~/.subversion}} directory
   

{noformat}
rm -rf ~/.subversion
{noformat}

1. Create a symlink to point to your Windows Subversion directory
   

{noformat}
ln -s '/cygdrive/c/Documents and Settings/$USER/Application Data/Subversion' ~/.subversion
{noformat}
\\
From now on, any Cygwin access to subversion will use your Windows-based Subversion settings, so you may now modify your Subversion settings in a single place.
{tip}

h2. Important Configuration Settings

|| Section || Configuration Option || Recommended Value || Description ||
| auth | store-passwords | no | Subversion stores passwords for https connections in cleartext on your filesystem. If you don't care, leave this alone. If you're like me, consider using SSH keys or be willing to type in your password for checkouts and commits. |
| miscellany | global-ignores | .classpath .project .metadata | There are some files we never want to be committed to the repository. For example, I use eclipse, and want to ensure that I never accidentally add my {{.project}} or {{.classpath}} files to the repository. Note that this option can be overridden as needed on a per-file or per-directory basis. |
| | enable-auto-props | yes | We typically will want the same SVN properties set for the same types of files without having to manually set svn properties for each new file in each new project. For example, we probably want to enable keyword expansion for all .java files, and set the executable bit for all .sh files. Auto properties allow us to specify automatic svn property setting for new files based on configuration per file extension. |
| auto-props | \*.java | svn:keywords=Date Revision Author HeadURL Id | |
| | \*.jsp | svn:keywords=Date Revision Author HeadURL Id | |

h2. Manually Settings SVN Properties

As mentioned in the previous section, auto-props can be used for SVN to assign properties to files that have not been manually assigned properties yet. But what if you have a project that was created before you changed your config file? Or what if you have a file type that isn't convered in your auto-props settings?

The {{svn propset}}, {{svn propget}}, {{svn proplist}}, and {{svn propedit}} commands can be used to set/read properties on files. For example, to enabled keyword expansion in a java file, you would type:
{noformat}
svn propset svn:keywords 'Date Revision Author HeadURL Id' MyFile.java
{noformat}
Similarly {{svn propget}} _property-name_ _filename_ will show the value currently assigned the property for that file. To view _all_ properties for a file, use {{svn proplist}} _filename_. To _edit_ all properties in a file, use {{svn propedit}} _filename_, which will open up your default text editor and all you to modify all the properties at once. These values will be assigned to the file once you save the document.
{code:title=Examples}
[robertd@P02968 csmcachecontroller]$ svn proplist CacheController.java
Properties on 'CacheController.java':

 svn:keywords

[robertd@P02968 csmcachecontroller]$ svn propget svn:keywords CacheController.java
Date Revision Author HeadURL Id
{code}