Wednesday, May 26, 2010

HEALTH: Interval Strength Training

If you do strength training, you probably know that your body can plateau and changing up your exercise pattern is a good way to kick your body back into gear. In an effort to do just such a kick start, my gym buddy and I often try new techniques. One such that we find very effective is what we call Interval Strength Training.

The term Interval Training is overused already, utilized for other techniques unrelated to what we are talking about here. While a better name is needed, when we use it in our workout routine, we always know what we mean by it.

You can call it what you want, but in context of this post, Interval Training is a method of simply changing the order of the weight changes in a set. Traditional methods do 3 sets of 10 repetitions (reps) of increasing strength: light, medium, heavy. It is also a good idea to always start with a warm up set that isn't counted in the above 3.

Interval Strength Training is a little different. We shock the muscle by jumping back and forth, and also change the reps per set. The first set is the traditional "light" set at 10 - 12 reps. Next, we jump up to our heaviest set at 4 - 6 reps. If you are able to do more than 6 reps on Heavy, than you have misjudged your weight selection and should fix it next time. The 3rd set is Medium; somewhere between the heavy and light, and should be 8 - 10 reps. Finally, we push out a set of what we call "Super Light" which is set below the Light set from before and we have to do 20 reps at this weight.

The method here allows for your muscles to work on heavier weights earlier in the workout before they fatigue, which will encourage muscle growth. The super light set at the end helps to build endurance as you push your muscles to fatigue. Our own application of this technique is to do 2 or 3 weeks traditional, then a week of Interval Strength Training to "change it up".

Give it a try and see the results. Feel free to report them here for others to benefit.

To Recap:
1. Light = 10 - 12 Reps
2. Heavy = 4 - 6 Reps
3. Medium = 8 - 10 Reps
4. Super Light = 20 Reps

Thursday, May 6, 2010

CVS: Using Perl to Restrict Commits

This is one of the most useful tricks I have used in terms of SCM controlling of a CVS repository, so listen closely.

CVS is a great tool, and a horrible tool all in once Open Source package. It can do a lot, but often it can do too much as well. In order to stand a chance of having a well controlled environment, it is often important to have CVS do some of the enforcement work for you. Let it be the bad guy instead of you.

First, check out the CVSROOT module from CVS:
$ cvs co CVSROOT
The most important file here is verifymsg. This file tells CVS which files to pay attention to when someone commits a file. In this file, we will tell CVS to restrict one file to a set of rules, and let another file slide no matter what. Take for example 2 subdirectories, one called GUI and one called TEST. Let's say we don't care about TEST code and can let developers change this stuff at will, but GUI is our production code that we want to keep tight control on. How do we control it?

We can either require them to submit some sort of change document like a bug id, problem report (PR), software change request (SCR), etc. OR we can put certain requirements on the content of the commit comment. The method I employed was to tie them to using SCR's that they had to create with a 3rd party tool called Serena ChangeMan Dimensions. It is a tool for Change Tracking (a critical SCM concept and we were able to do it by doing this hacked integration of CVS and Dimensions. A tighter, more seamless integration already exists with Bugzilla and CVS, but we are not always given flexibility to use the tools we want to use, so we figure out how to use the tools we have to use.

In any case, in order to require them to create an SCR in Dimesnions for each check in, we will need to do a few steps:
1)    Tell CVS which files to NOT-enforce on in verifymsg
2)    Write a perl script to check the commit message for an SCR number. This perl script is the key--if we wanted to make sure they wrote a full sentence in their message instead of checking for an SCR number, we could do that here instead too.
3)    Tell CVS which files we DO want to enforce checking on and point it to the perl script created above to verify the commit message.
4)    Commit the verifymsg file to CVS
5)    Ensure the script is executable by everyone.
Now to work on the perl script. A good place for it would be /usr/local/bin, but you can put it anywhere you want. This is going to be a perl script. Don't know what Perl is? It is not something precious made in clams and strung around a pretty girl's neck. It is a powerful scripting language. That is all I will say about it here. If you want to know details, visit or My goal here is to just show the shortcuts to get the job done, without delving into the guts of any of this.

So we'll start with an empty file, call it, and place the following in the very first line of the file to declare it as a perl file:
#!/usr/bin/perl -w
Next we will place a BEGIN command to tell perl that this block of code should be run as soon as possible (even before the rest gets compiled). In this block we will set $valid=0, and at the end of the file, we will return this variable. This is what our code looks like so far:
#/usr/bin/perl -w
  $valid = 0;
The purpose of this block is so that, even if there is a problem interpreting the rest of the perl script, we can still give something back for CVS to understand. Namely, we will immediately set the check to fail, so as a default if the script fails right now, the whole CVS commit will be denied. This is a safety precaution since we don't want developers to commit code that doesn't meet our requirements just because there is a typo in the perl script.

On to the meat of the perl script. Each line is being interpreted individually in this script. What we are analyzing is the text content of the CVS commit comment. We will encapsulate the check within a while loop and want to read the input from STDIN (which is the CVS commit comment that is being sent in). Type while (<>), then we will put the rest in curly braces. The next part is where perl shines--using a regular expression to find the SCR number and capturing it to a variable. In this example, I required users to type "SCR: " followed by the SCR number. The perl script will find that token SCR: and then look at the SCR id right after it.
if (/^SCR:\s*([A-Za-z0-9_]+[SCR|scr][_0-9]+)/)
Goodness that looks complicated, and I wont lie to you, it is! But let's simplify it. Obviously the if statement is just a simple common programming construct, so we'll skip it. The ^ indicates that we are looking for something at the beginning of the line. Without the ^ it will try to match the SCR: anywhere in the line. This is preference, but I believe they should have this SCR number declared in the beginning of a line, not embedded in the middle of a sentence. Much cleaner that way. We already answered the next part...the SCR: after the ^ is just an exact text string we are looking for. The \s is vital magic here; it tells perl that everything within the that matches the regular expression within the proceeding parenthesis will be stored in predefined variable $1. Ex. if the CVS commit comment is "SCR: PROJECT_SCR_22", it will parse out only the PROJECT_SCR_22 into $1. Now we tell perl how to find that PROJECT_SCR_22 string. The [A-Za-z0-9_] means find any combination of UPPERCASE or lowercase letters and numbers, all followed by an underscore. PROJECT_ matches, as well as ProJect_, or even MAcH5_. The + that follows actually doesn't mean "plus the following" as intuition leads you to believe--it actually means "at least one or more of the previous".

I will diverge for just a slight moment. What we are using in the above "if" statement is what is called a regular expression and is found in much more than just perl. Often the syntax is very similar, or seemingly exact, but keep in mind we are still doing perl here.

We left off looking for any string that contains at least one UPPERCASE, lowercase, number, or underscore. In my implementation, I have multiple SCRs for multiple projects, so there is ABC_SCR_1, XYZ_SCR_1, and JoeSmith_123_SCR_1. All are valid SCRs, so our perl regex (short way of saying regular expression) says to look for basically anything, followed by the string "SCR" in either UPPERCASE or lowercase. I didn't allow mixed case in this example. So the next part, right after the first + we saw, is the [SCR|scr]. As you may have guessed by my previous statements, this means find the term SCR or scr. The pipe operator "|" means or in this case. Again, only all UPPERCASE or all lowercase is matched, not mixed case. Notice that I did not put a + sign after this square bracketed part. The reason is I don't want to find SCR "one or more times" nor do I want to find it "zero or more times" (which is what * would mean)--I want to find it one time and exactly one more, no less. At this point, we now have some string indicating the project, then we have the SCR keyword that we have to find, and finally we'll look for some number. That is the [_0-9]+ part; we look for any number, but again it has a + sign so we have to least have SCR followed by some number. It could be 3, 10, 42, or even 2395678542.

Once we close the parentheses, this tells the "s" which was placed before the first parenthesis that the string we just matched will be placed into $1. Note, if you had placed multiple instances of s(some_regex), they would incrementally be matched and placed into $1, $2, $3, etc. Place another close parenthesis to close off the "if".

Now that the hardest part is done, we'll breeze through the rest. Create an open curly brace to say that we are going to put a block of code that will be executed if the if statement above succeeds. In here we will do a bunch of things at once:
   my $scr = $1;
   print "We matched $scr from your commit comment\n";
   $valid = 1;
First line puts the matched string into a variable called $scr. The print line is just a message we are printing to screen to let the user know what we are doing. Since we used $1 in the print line, it will show them the string we matched. The \n just passes in a new line. We could get fancy at this point and wait for a user input to verify if we matched the right thing...but not in this post. Finally, we set the $valid variable that we used in the BEGIN statement. Remember that we assumed it is immediately false back in the BEGIN, but now we are setting it to TRUE. So if we get to this line and set this variable, when we exit the script, the CVS commit will succeed.

Close up the Curly braces now for the if statement and while statement, then put an "exit !($valid)" and we are all done. The final product looks like:

#/usr/bin/perl -w
  $valid = 0;
while (<>)
 if (/^SCR:\s*([A-Za-z0-9_]+[SCR|scr][_0-9]+)/)
   my $scr = $1;
   print "We matched $scr from your commit comment\n";
   $valid = 1;
exit !($valid)
Our Perl script is done, so now to tell CVS when to use it. Edit the verifymsg file from within the CVSROOT module we checked out. At the end of the file, we are going to add another regex to catch commits and route them to the perl script. Going back to the example started at the beginning of this post, we need to put a line in this verifymsg file to tell CVS that all code in GUI needs to have an SCR, but all code in TEST does not. This is how:
^TEST     /bin/true
^GUI       /usr/local/bin/
Remember, we saved our perl script from above in the /usr/local/bin folder, so now we are calling it when the CVS commit matches the ^GUI line. The carot (^) is a regex notation for "the beginning of the line" so it is looking for GUI as the first word in the line. If GUI and TEST were part of a larger module, say CODE, then it would be ^CODE/GUI.

Security warning: The file /usr/local/bin/ needs to be executable to all users (or at least those in the cvs group), but should not be editable to anyone. Make sure to change permissions accordingly.

Save and commit the verifymsg file. Keep in mind that CVS will match only the first instance in the verifymsg file, so if you have something that matches 2 regex lines in verifymsg, only the first one will be used.

WEB: Google Webmaster Tools, Sitemaps, and Blogger/Blogspot

Today I looked at my Google Webmaster Tools and once again puzzled as to why the sitemap kept showing an error. My site was not indexing properly and this was really bugging me. I submitted atom.xml as a sitemap and it failed. I submitted rss.xml as a sitemap, and still it failed. The failure is not as bizarre as the fact that I host 2 different blogs on and the old one works fine using atom.xml as a sitemap, but the new one (this one) refuses.

Finally, after some web searching, I stumbled upon an answer. Using "feeds/posts/full" as the address for the sitemap seemed to work.

So, if you are trying to get the sitemap to work in Webmaster Tools, follow these steps:
1)    Log into your Google Webmaster Tools account (
2)    Click on your site--we are assuming you already created your account and verified the site
3)    Click on Sitemaps under Site Configuration
4)    Click on Submit a Sitemap
5)    At the time of this post, doing the above shows a box that has the base web address filled in and an empty text field to add the location of the sitemap. In this empty text field, add feeds/posts/full and click Submit Sitemap.

That's it! It should show up shortly. Check to make sure there are no crawl errors and you are done.

Tuesday, May 4, 2010

HEALTH: Tips from a Body Builder

Well, this blog cannot survive as just a purely technical blog. Especially not with me as an author. A month ago I bought a Venus Fly Trap; today I was considering buying a Mango Tree to grow in a Hardiness Zone 5 region and was thinking about learning Bonsai techniques so I can prune a large Nam Doc Mai Mango into a size able to be grown in a container. My point is, my brain does a lot more than think about technical things and my wife is loving and patient enough to let me entertain some of my weird passions/hobbies. Heck, last week I freelanced as a second photographer for a friend of mine who is a professional wedding photographer!

So, while cleaning up some files on my computer, I found a document I jotted down some notes in from 2 years ago. My cousin's husband was visiting America for a Body Building competition and stayed with us for a few days. He gave me some great tips on how to get in shape and get definition in my body. I do go to the gym a few times a week and martial arts occasionally, so this advice might have stood a chance of being followed, but my laziness won over and I have never actually followed his "plan to bodily perfection". However, I will share it here so this jewel of information is not lost and perhaps someone will benefit from it.

--) 2 eggs (whites only)
--) Oatmeal or potatoes for carbs
All meals
--) Avoid fried or oily foods but anything is good
--) Sweets are okay during day
--) No sweets after 6pm
--) Eat protein before sleeping
--) No sweets
--) Avoid carbs (can eat but very little)
Working out
--) 30 min to 1 hour before workout
~~~~~) Whey protein prior to strength training
--) Immediately after workout
~~~~~) 5 tablets of Amino Acids
~~~~~) 5 gram scoop in water of Glutamine
--) 3 times a week, cardio
--) Massage muscles often
--) Sauna every 15 days (jump in cold water immediately after)

Sunday, May 2, 2010

CVS: Getting into the mind of CVS and how it works

Since some of my posts are discussing manipulating CVS backend files, it is important to now explain a little bit about the way CVS works.

CVS only cares about its own copy of the code in $CVSROOT. Each folder under $CVSROOT is called a module. The files in here are kept in the same structure with the same filenames, EXCEPT every file has a ",v" at the end of it. No need to go into why, just understand that these are the backend files of files under CVS control and that each ",v" file contains all the version history of the file in it. Developers should NEVER be here, never look here, and I have probably done wrong just telling you about it because your curiosity may cause you to go look in this folder. Screwing up something here can be disastrous.

So why doesn't CVS care about your files? It doesn't need to until you try to do something using the "cvs" command. First you do a checkout to get code to your local area to work on.
$ cvs co <module>

The "co" is a shortcut for "checkout" but either can be used. This will get the latest copy of the code out of CVS, called the HEAD...or the HEAD of the TRUNK. We can talk more about HEAD, TRUNK, BRANCH later when we talk about proper revision control

Once the code is checked out, you will notice a CVS sub-folder in every directory. This CVS folder contains the information about
1. Where the CVS repository is (can even be on a remote machine -- this may hardcode usernames)
2. What module you have checked out from the repository
3. What tag/branch if any
4. What versions of every file is checked out

If this CVS folder gets deleted, there is no link back to CVS. When you do a commit to CVS, it goes into this folder and looks up the data on where to put the files. It will also do checks to make sure you have the latest code prior to allowing you to commit. There is a nuance to be aware of when using code on remote servers: If $CVSROOT is on a remote machine, then your Root file in CVS folder probably contains a :pserver: line with your username hardcoded. This means that, if you are sharing code with another developer (copy and paste whole directories), they will get your username all over the place. I wrote another blog post on how to quickly correct this problem. If the CVS repository is on the same server as you are checking out code to, this problem isn't manifest.

We'll talk more in later posts about how to manipulate CVS in the backend for restructuring code. This a dangerous, but occasionally necessary task.

CVS: Changing username in CVS/Root files

It is possible to share a CVS checkout that has been compiled (to avoid having everyone need to recompile it) by just changing the username in the Root files. This only really applies if your code resides on a remote server and you are using :pserver: or some other protocol that hard-codes your username into the $CVSROOT.
find -path '*CVS*' -name Root | xargs perl -p -e "s/pserver\:<user1>/pserver\:<user2>/g"

This changes <user1> to <user2>. For debugging purposes, the test executables have the source file locations hardcoded. So even if the directory is copied and the above change is made, debugging will still point to the original file locations (if it exists). This also happens if using shared objects or dynamically linked libraries rather than static libraries. This is frustrating but does not defeat the usefulness of this concept.

WINDOWS: Permission Denied to Network Drive/Share

A strange case manifested itself where a user could not log onto a Linux Samba share drive. He could log on from another machine, so there was no problem with the share, but while attempting access through his Remote Desktop session on the server, he was given a message about being locked out or permission denied to the shortcut or network resource. An odd solution did the trick; searching for the computer, creating a link on the desktop for it, then opening the link works fine to connect to the share. After that happens, it will work from the original link.

Using Search/files and folders/computers, search for the network/computer name
The computer should be found. Clicking on it from here will still not work.
Make a shortcut of the found link on the desktop.
Then clicking this desktop shortcut, you will be taken to the computer/server you were looking for.
The strange part is, now, after clicking on the shortcut, both the original link and using \\<server name> from the address bar will work.

Saturday, May 1, 2010

PIBS: Changing Speeds/Frequencies

While setting up a factory AMCC 440GX Eval Board, it may be necessary to change the default settings for frequency, CPU speed, etc.

To change the boards to 533MHz for the CPU speed, use the following command in PIBS:
chipclk prom0 cpu 533333333 152380952 76190476 76190476 152380952 30000
To change the boards to 800MHz for the CPU speed, use the following command in PIBS:
chipclk prom0 cpu 800000000 133333333 66666666 66666666 66666666 30000

Type "help chipclk" into PIBS to see information on what all the arguments mean. The above commands switch back and forth between the two configurations.

GHS: Flashing networking settings to kernel on board

After the GHS Integrity Kernel boots for the first time, the IP address and Netmask need to be set again and saved there to non-volatile memory. These commands should be run after the Kernel banner is displayed and commands can once again be typed into Hyperterminal. A quick test would be to first type "help" to see if the Kernel help menu is displayed (this is different than the PIBS help menu). There is no prompt so just type the following into the empty area below the Kernel banner:
nc I
nc s
nc N
nc s
nc H Board3
nc s

The "nc I" sets the IP for the board (customize it appropriately), the "nc N" sets the Netmask, the "nc H" sets the Hostname of the board that is displayed when the banner comes up, and the "nc s" after each command saves the info to non-volatile memory. You could just type the "nc s" once at the end instead of between each command--depends on your level of paranoia.

PIBS: Timeout or Connection Refused

If using FTP or mounting an NFS share or doing some other network related activity on the board (other than connecting Multi with RTSERV), timeouts or connection refused messages may occur. The solution is simple: If the date/time on the board is way off it will need to be set correctly. Use the following:

PIBS $ dateset YYYY MM DD
PIBS $ timeset HH MM SS