Tip of the month

Ah:

to transform or not to transform

that is the question.

I guess by now almost everybody knows that my personal preference is:
Only transform unless there is no other way out.

First of all if you want to export things back out of XPP, then transforming on the way in is evil. Simply because you will have to un-transform your modifications on the way out. And don’t forget that you will loose the ability to parse online (unless you start modifying the DTD/Schema as well).

Josh was precise enough though to specify that his transformation example was best used when you work in a ‘into XPP-only’ world.

Still even in such a scenario, I still think that it is better not to transform.
The rule:

“Solve within compose what you can solve within compose”

still applies.

Solving things by adding transformations will make style maintenance in the long run more complex and less efficient.
Don’t forget that with XPP we have WYSIWYG editor to resolve and fix remaining problems very quickly and efficiently. Here are the typical steps an XPP style editor will go through to correct a problem:

• Go to the page, click on the trouble area
• do CTRL/y and the system will bring up the appropriate macro or if rule
• make your changes, save
• compose one page
• verify that your change is successful

Hard to beat that short correction cycle.

Compare this to finding a solution with a transformation rule involved:

• go to the right spot in the document
• verify the context
• open your XSLT program in a different editor
• locate the rule you want to modify and make your changes
• store the changes

re-import and re-transform the document

• compose the whole division
• go to the trouble page and verify that you did indeed fix the problem

Oh you might think, so how can I solve this ‘first’ para problem within compose?
Well easy: add a rule to your IF and specify in the SGML/XML Path field:
para[1]

Now I really wish we could solve ALL our composition problems as easy. But unfortunately that is not the case yet, but we are getting closer with every release. So for the moment there are still cases left where we need transformation….but still “transformation is evil” should remain our credo.

So Josh, keep the XSLT tips flowing…we like and appreciate them.

This is from the perspective of a UNIX sysadmin.
One of the issues with having multiple users logging on to the UNIX server via exceed is the problem with zombie processes if the user logs off and the UNIX server does not know it. Now there may be a great way to solve that problem, but since 2002 I have been handling through a csh script.
Since I am running UNIX and am in the process of moving to Windows I have no need to change this script.

##########
#!/bin/csh -fb
# zap_old
# gary nadeau Jan 30, 2002
# use to clean up users left on from previous day(s)
# culprit (somtimes) is the users exceed config is not set correctly.
# xconfig, Screen Definition, Common Settings, check box “Exit On Server Reset”
#
set today = `date|awk ‘{print $1}’`
finger | grep -v “$today “|grep -v Login | cut -c32-40 > zaplist
foreach zap (`cat zaplist`)
/appl/xyvision/xz/bin/zap “$zap ”
end
exit 0
################

this looks to see who is still logged on if $today is not the current day. This is interactive and the operator must answer ‘y’ to each prompt but it has been very helpful over the years.

I run three scripts as part of my daily routine. First one pings each server to make sure they are up
#!/bin/csh -fb
ping svappl17
ping svappl18

the second runs “finger” on each to see who is logged on
#!/bin/csh -fb
echo “svappl17″
rsh svappl17 finger
echo “svappl18″
rsh svappl18 finger

the third runs “uptime” on each to see the load on my servers.
#!/bin/csh -fb
echo “svappl17″
rsh svappl17 uptime
echo “svappl18″
rsh svappl18 uptime

Armed with this information, it makes it easy to determine the next course of action if needed.

I realize this is not rocket science, but I have found that making sure the servers are not over taxed helps all around. With 300+ users I find this a very useful “suite” of scripts.

Which makes me wonder what month we are now at?
Josh = tip of the month for February 2010
Gary = tip of the month for March 2010
Paul = tip of the month for April 2010

It looks like we are filling up the year pretty quickly…