This is from a document I recently wrote intended to provide examples and guidance for running certain scoped propagation scenarios for a client. The examples were done using an application I had handy at the time, and actual results of scoped-based propagation are application-specific, so your mileage may vary.

Scoped propagation should be tested in lower environments prior to running propagation with a Production destination. The scope properties file used for scoped propagation must be revised each time scoping is used to ensure all desired nodes are propagated.

With careful testing and experience, scoped propagation can be very useful. Without testing, scoped propagation can lead to unrecoverable state for the portal functionality. Debugging propagation scope seems at first difficult, though once an intuitive understanding of Important Scope Notes is achieved and experience obtained reading the propagation logs, configuring the scope.properties file becomes much simpler.

Important Scope Notes

The following concepts around scoping must always be considered when using scoped propagation to minimized risk.

Any scope listed will automatically include all children of that scope

If the Application\:SecurityService\:SecurityProviderService node is listed in the scope.properties files, all children of Application\:SecurityService\:SecurityProviderService will be propagated, regardless if they are specified or not.

Dependency Checking

One example of a dependency check: If a portlet (or any asset that can be entitled) is in scope and the definition of the role is out of scope and the role does not exist in either environment, the entire propagation task will fail.

The variety of dependency checks that will occur for default nodes are far too numerous to be listed, and the possibilities increase exponentially with each application-specific node. There are two purposes to pointing out dependency checking in relation to propagation. First, that the use of scoped propagation where all dependencies are not explicitly known in advance can have undesirable functional side effects. The second is that due to the complexity of potential dependency relationships, relying on the propagation servlet to detect all dependencies is a very risky assumption and not recommended or supported.

Examples and Assumptions

my_propagation_ant.xml is the propagation Ant build file used for the tests and based on the examples in the standard WLP documentation and the one that comes installed with WLP (<WLPORTAL_HOME>/propagation/bin/propagation_ant.xml).

The examples below assume all files are contained in the root of the working directory and that the commands are run from that same location. The examples also assume that default policy properties are used.

Common Scoping Steps

These steps will be referred to or repeated throughout this document with minimal change:

1. ant -f my_propagation_ant.xml downloadSrc
2. ant -f my_propagation_ant.xml listScopes
3. Starting at the parent node, remove all nodes of the undesired scopes from the resulting listScopes_scopes.properties file and save as scope.properties
4. ant -f my_propagation_ant.xml downloadScopedSrc
5. ant -f my_propagation_ant.xml downloadScopedDest
6. ant -f my_propagation_ant.xml combineWithScope
7. ant -f my_propagation_ant.xml uploadCombined
8. ant -f my_propagation_ant.xml commit

Scoped Propagation: No Content

This is a basic scenario, and one that is listed under Best Practices for propagation. These steps have a high likelihood of success used as-is in most environments.

Steps to perform scoped propagation where all managed content is left out of scope:

1. ant -f my_propagation_ant.xml downloadSrc
2. ant -f my_propagation_ant.xml listScopes
3. Remove all nodes that begin with scope_[#]=Application\:ContentServices from the resulting listScopes_scopes.properties file and save as scope.properties
4. ant -f my_propagation_ant.xml downloadScopedSrc
5. ant -f my_propagation_ant.xml downloadScopedDest
6. ant -f my_propagation_ant.xml combineWithScope
7. ant -f my_propagation_ant.xml uploadCombined
8. ant -f my_propagation_ant.xml commit

Scoped Propagation: No Security

In propagation scope, Security specifically refers to the definition of Security Services under the Application\:SecurityService node. These values can be scoped to a very fine level, keeping in mind the limitations listed under Important Scope Notes. With this in mind, follow the Common Scoping Steps with the undesired Security Services scopes removed.

Scoped Propagation: Desktop

Propagating admin-only changes scoped to a desktop level is very straight-forward. At step 3 of Common Scoping Steps, all nodes that do not start with the individual desktop node should be removed from the listScopes_scopes.properties and saved as scope.properties. The general format of the node is:

scope_[#]=Application\:portalservices\:[APP_NAME].WebApp\:[PORTAL_NAME].Portal\:[DESKTOP_NAME].Desktop\:[DESKTOP_NAME].DefaultDesktop

Again, keep in mind the Important Scope Notes.

Scoped Propagation: Roles and Entitlements

Entitlements are entirely dependent on roles. If an asset is entitled, it cannot be propagated if a role entitled to it is not present or propagated[1]. In order to de-scope a role from propagation is also necessary to de-scope all assets entitled to that role.

Barring the long-term partner projects, I find there are three types of consulting engagements when you work for a product company:

Strategic: Getting the project off the ground

Tactical: Providing a solution to an isolated slice of the client project

Rescue: For the clients who thought about the first two engagements, rejected them, and then got stuck

An experienced product consultant will have experience across the full SDLC, but rarely for a single project. This is simply an observation and not positive or negative outside of the subjective context of the individual consultant.

Have you experienced another type of engagement? Post it here as a comment!

http://humor.fywservices.com/2010/08/milking-technology/

Today’s post on my joke blog should strike home with readers of this blog.

This thread is a must-read if you are a consultant or ever thought of being one. Free LinkedIn membership required.

In response to the following question on LinkedIn today:

R&D time – how do folks manage it? – similar to Google’s 20% research time – free form, scheduled, pros-con’s – approved projects…looking for suggestions.

<RANT>
The old rule of thumb was that a senior IT professional should be engaged in deliverables only 65% – 85% of the time (depending on budget and the intelligence of management). The “unproductive” time was when R&D occurred, along with training.

These days, most R&D I see happening is when it is built into a project plan (either through creative padding or selling the ROI in advance and within a short time frame).

What little R&D I do see happening between projects these days is structured by people too far removed the deliverable level. As such, the time lines are too aggressive and the focus towards mindless repetition of simple examples rather than understanding the technology by stretching it to see what it is capable and where else it will apply.

</RANT>

I wrote this a long time ago on a Blackberry in a fit of frustration on a project…it still cracks me up

In an effort to reduce the strain on some clients who seem to have difficulty adopting the RUP process, I present to you an alternative methodology based on a model of what they’ve accomplished in the past and continue to strive for in the present.

First, schedule the project. Any project worth doing should have a deadline, and this needs to be set immediately after coming up with a catchy-yet-vague project name. Really import projects require the deadline to be set before the project is named.

Once a completion date is set, work backwards to build a full schedule. If the date is 6 months away, we know it takes as long to do QA as it did to code, so code freeze will be in 3 months. Everyone realizes that requirements need to be gathered, approvals gained, and designs considered, so let’s plan to do that at the same time. Just to make sure there is enough time to get it all done, give it 4 months. The math is clear: start the project last month.

Next, program something. Anything. We’ll find a use for it somewhere. Yes, we’ll give you requirements just as soon as we decide what the project is. And while you program, please create a design document to show that you used design. To make sure it is an accurate description, write it after you’re done coding. Also, please make all documents as boring as possible so others don’t waste valuable company time reading them.

Laugh maniacally to prove you are fully stressed. If you are stressed, then we have an accurate deadline. If you’re relaxed we obviously gave you too much time. If you’re just burnt out, you’re probably faking it. We have a perfect schedule, everything is on time, and if it’s not on time we can always change the requirements to be on time. We also reserve the right to change the requirements if we happen to feel like it. We’ll let you know critical changes during QA so you can add it in while you fix bugs.

Announce publicly the full functionality and the release date of the project. This should be done prior to QA. Also, to build public awareness and industry anticipation, announce that this service is availablet, program something. Anything. We’ll find a use for it somewhere. Yes, we’ll give you requirements just as soon as we decide what the project is. And while you program, please create a design document to show that you used design. To make sure it is an accurate description, write it after you’re done coding. Also, please make all documents as boring as possible so others don’t waste valuable company time reading them.

Laugh maniacally to prove you are fully stressed. If you are stressed, then we have an accurate deadline. If you’re relaxed we obviously gave you too much time. If you’re just burnt out, you’re probably faking it. We have a perfect schedule, everything is on time, and if it’s not on time we can always change the requirements to be on time. We also reserve the right to change the requirements if we happen to feel like it. We’ll let you know critical changes during QA so you can add it in while you fix bugs.

Announce publicly the full functionality and the release date of the project. This should be done prior to QA. Also, to build public awareness and industry anticipation, announce that this service is available now.

Test the application. Hey, we planned for QA early on, and we’re doing it! Be sure to only test the user experience, because this is all the public and our non-IT departments understand. If all of the data is wrong, that’s a production issue. The guys in production have nothing to do anyway, right?

Throw it away and try again. Nothing worked the way it was supposed to, no one uses the software, and we’ve identified a scapegoat (read “lead developer”). Bring in a consulting firm to fix it all. And remember, we have this process in place and we’ve used it before. It’s documented. So make sure the consultants follow this method.

Like any methodology, it needs a catchy acronym to be considered a real process, so lets look at what we do and see what it spells (we would never consider coming up with the acronym and then trying to make the process fit J):
Schedule
Program
Laugh insanely
Announce it’s finished
Test it
Throw it away.

So, there you go. As a viable alternative to the RUP process, I offer you…

SPLATT!

Ed note: This was posted on my old site in 2004. Every time you think we are making progress in computing, read this

In Japan, they have replaced the impersonal and unhelpful Microsoft error messages with Haiku poetry messages:

Your file was so big.
It might be very useful.
But now it is gone.
————————-
The Web site you seek
Cannot be located, but
Countless more exist.
————————–
Chaos reigns within.
Reflect, repent, and reboot.
Order shall return.
—————————–
Program aborting:
Close all that you have worked on.
You ask far too much.
——————————
Windows NT crashed.
I am the Blue Screen of Death.
No one hears your screams.
——————————–
Yesterday it worked.
Today it is not working.
Windows is like that.
———————————
First snow, then silence.
This thousand-dollar screen dies
So beautifully.
———————————
With searching comes loss
And the presence of absence:
"My Novel" not found.
——————————–
The Tao that is seen
Is not the true Tao-until
You bring fresh toner.
Stay the patient course.
Of little worth is your ire.
The network is down.
———————————
A crash reduces
Your expensive computer
To a simple stone.
———————————
Three things are certain:
Death, taxes and lost data.
Guess which has occurred.
———————————
You step in the stream,
But the water has moved on.
This page is not here.
———————————
Out of memory.
We wish to hold the whole sky,
But we never will.
——————————–
Having been erased,
The document you’re seeking
Must now be retyped.
———————————
Serious error.
All shortcuts have disappeared.
Screen. Mind. Both are blank.

The most dreaded question for an IT professional is “What do you do”?

I’ve finally found the answer. I solve problems.

What kind problems? All kinds. The key piece is, my efficiency in solving a problem is directly proportional to how interesting I find the problem. It’s true for all IT pros.

For an MIS guy, it’s fascinating to find the best way to get file A to point B while keeping away hacker C.

For a Web Services guru, it’s all about getting data from one place to another, and the further apart they are, the more interesting it is.

I have a lot of problems I find interesting, but the one I find most interesting is how to get user A to use system B and for system B to do something useful with system C while user A has no idea that there is a system C. It just happens.

That is what I do.