Duke proposed a PDX.pm sprint to work on 5.10.1:
“I think if everyone learns how to

a) get a copy of the perl git repo
b) keep it in sync
c) run the perl test suite, including running a single test at a time
d) submit a small documentation patch

then we will have a great start.”

This is perfect for a first sprint: “small, solve-able tasks” that will get everyone up & running, plus have the potential to actually be productive.

Your first code sprint with a new group of people is like the first day on the job…except nobody realizes that we’re each FNGs*. It can take some time to figure out how to work together.

It’s really great if people get the stuff that’s going to take time from the code sprint out of the way beforehand. For example, cloning the perl5 git repo (step a):

:::=>git clone git://perl5.git.perl.org/perl.git

(Took me 13 minutes.)

Duke suggested some advance reading as well – how to use the repo (cd perl; perldoc pod/perlrepository.pod) (you will need to install perl-doc if you don’t have it; it was not installed on ubuntu.)

–

At the sprint: I don’t have the necessary experience with git yet, so most of my time was spent learning that, specifically in regards to task b) Keeping your repo in sync.

git branch
shows me that I am on the blead branch

git remote show
just an interface into .git/config

git pull
convenient combination of fetch (from remote) + merge (into local stuff)

git pull origin
…by default pulls your current branch.
git pull
…would have done the same thing (depending on your .git/config!)

The blead branch is NOT what perl 5.10.1 is going to be released from, so that’s not what we’re going to work with.

Side trip:
Duke has an excellent graphic that he & jhelwig created that illustrates git as applied to the perl development process**. (I think I convinced them to put it into an actual graphics program & make it available…) One of the tips I got from the diagram was that tags are immutable. They should not move. If they move, UR DOIN IT WRONG.

perldelta.pod – manually-maintained (!!!) filed that lists the changes in all versions of Perl.

OK back to work:
How to check out maint 5.10: (remember, blead is beyond 5.10 & has changes we don’t need to be concerned with.)

git checkout -b
…is a combination of checkout and branch

git branch -a
…shows me all the branches I have locally.

I want to create a *local* tracking branch for 5.10 maint.

git branch [whatever I want to call it] [branch I want (or anything that can uniquely id a commit!)]
eg:
git branch maint-5.10 origin/maint-5.10

Tip:
git config --global color.ui auto
- git branch -a – local branch is white, currently checked-out is green, remotes are red.

THEN I need to actually check out the local tracking branch (ie switch to it)
git checkout [name I gave it]
eg:
git checkout maint-5.10

git checkout -b maint-5.10 origin/maint-5.10 is a shortcut for the above two steps.

–
c) run the perl test suite, including running a single test at a time

For reference:
:::--> uname -a
Linux princess 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC 2009 i686 GNU/Linux

First, you have to build (opts from Schwern, modified)
sh Configure -Ode \
-DDEBUGGING \
-Dprefix=/usr/local/perl/maint-5.10 \
-Dusedevel \
-Duseithreads \
-Dccflags='-I/usr/local/include -I/opt/local/include -I/sw/include' -Dldflags='-L/usr/local/lib -L/opt/local/lib -L/sw/lib' \
-Dlibpth='/usr/local/lib /opt/local/lib /sw/lib /usr/lib' \
-Uversiononly \
-Uinstallusrbinperl $@

- DEBUGGING builds the debugging symbols
- usedevel is required or configure will BITCHBITCHBITCH.
- useithreads enables one interpreter thread to do something I hope I don’t ever have to deal with. Or something.

Then:
TEST_JOBS=9; export TEST_JOBS #parallelizes your tests
make test
to compile perl and then run the tests. This takes a while. Grab a beer. In fact, grab a pitcher. Pay attention though, because a failing test here might be something interesting to patch.

make test TEST_FILES=[file] to run a single test.
e.g.:
make test TEST_FILES=t/pod/podselect.t
This turned out to be unreliable because it’s running through all the dependencies first. Bleah.

This is a better method:
cd t; ./perl TEST ./pod/podselect.t
Although Duke had problems with the debugger tests.

Remember TEST tries to cd to ./t, so you need to give your path relative to that.
(@Theory has more about this in his blog.)
(This is actually covered in perlhack, we just didn’t find it in time.)

–
Another tip:
get the name of your branch on your prompt. You need __git_ps1. Which is…somewhere halfway through the second pitcher.

Then add that var to your bash prompt whereever you’d like it:
$(__git_ps1 “(%s) “)
…the (%s ) is just my preferred formatting. The whole thing looks like this:
PS1=’\n\u@\h\w/\n$(__git_ps1 “(%s) “):::–> ‘

You can get some pretty colored output with this:

https://launchpad.net/~git-core/+archive/ppa

–
git shortlog:
shows you the commit messages, grouped by author. Useless if you’re looking for anything other than “a bunch of people did things.”

git shortlog -se:
number of commits, grouped by unique author + email.

git log --pretty=oneline maint-5.10..blead
…shows you the differences between two versions. In the perl source, there may be duplicates (different commit ID for same commit.)

–
Now let’s actually *do* something.
Stuff that’s holding up perl5.10.1 (I think)
Other stuff is in perltodo, but I’m not seeing anything that I’m actually up for given my skillset & current BAC.

I need to look for a doc to patch.

–
Annnnnd we decided to go to whiffies for pies.

More later! This is going to be a regular event.

–

* F’ing New Guy.
** Keep in mind that I am slightly more familiar with the Postgres release process & was expecting something similar.

my @things = split(/-/, $value);
[do cool stuff to @things]
my $new_value = join(/:/, @things); #D'oh! Should be join(':', @things);

I understand why (split can take a regexp, join must be on a specific value) but that doesn’t mean it still doesn’t trip me up. When I get time, I’ll write something that will let me put my arrays back together the same way I took them apart.

QA concepts are already familiar to me from my time as a microbiologist/immunologist with the FDA. We had a QA division that evaluated us quarterly in the following areas*:
Safety:
- appropriate gear (lab goats, goggles, gloves appropriate for what you’re handling)
- OSHA regs (aisle spacing, fire extinguishers, etc)
- drills (fire, acid spill, etc)

Keeping things neat:
- do we have expired chemicals hanging around
- are we keeping our documentation up-to-date and readable
- record-keeping (temperature records for fridges & incubators)

Calibration:
- solution & culture standardization
- instrument calibration (making sure all the lasers point the right way!)

Here’s how I relate this to software testing:

Safety equipment:
Backups & version control. If you have these, you can get yourself out of anything. Remember to practice restoring your backups.

Keeping things neat:
perltidy & perlcritic are your friends. (I still say perlcritic needs to have a drinking game that goes along with it.) Keep your code & documentation fresh.

Calibration:
Testing. Making sure that, given a certain input/environment, your code will produce certain output. For a while I confused testing with error handling – but error handling only deals with a certain set of inputs/$ENV. You want to include error handling in your testing – make sure that something that should throw an error actually does.

Once I got a grip on what I wanted to do, I had to figure out how to accomplish it. Learning how to use the tools was the hard part. Hard enough, in fact, that it took me a year of sporadic false starts before I actually did anything productive. I’m not blessed with a separate QA team for my programming tasks; I have to do it myself, but that is no excuse for having crappy code.

My largest project is my own fork of NMIS, which has no existing tests. (It may now, I forked it a while ago.) I went for the low-hanging fruit & started by testing a simple subroutine that altered text input:

my $ifName = "Serial1/0/0.0";
is (convertIfName($ifName),
'serial1-0-0-0',
'convertIfName should replace non-alphanumeric chars with hyphens and lowercase the whole schmear'
);

Over the course of 3 days, I wrote something like 200 tests.(eta actually I think I mean assertions. I’m still learning the lingo.) These were all simple unit tests (basically, does this one little block of code do what it’s supposed to do). I haven’t started yet with integration testing (does it play well with others).

The Payoff:
- I gained a much better understanding of how my code works. And found some interesting glitches – edge cases that (in theory, anyway) would never be executed in the existing production environment, but should probably be tested for anyway in case I decide I want to use them somewhere else.
- I found a lot of unused code & duplicated code, and places I could use now-standard Perl modules (like I said, my fork is old).
- Best of all, I can change my code (at least the parts I have tests for) at will and not worry that I’m going to screw something else up.

Glitches I hit:
- I already have been bitten in the ass by an edge case.
- Haven’t experienced any time savings yet, due to the learning curve.
- I’m about even with aggravation savings at this point – I am taking the next steps (mocking objects, getting ready to test an actual script^Wprogram instead of a module) and it’s like starting all over.

Places I’ve found answers to my burning testing questions:
- perlmonks archives
- stackoverflow
- Perl-QA wiki
- my local .pm IRC

—

* artificial categories which made it easier to draw parallels with software testing; thanks to Peter Eschright for the great idea from his talk at the recent BarCamp Portland.

1. Viewing data structures:
Data::Dumper::Simple
with:
$Data::Dumper::Indent = 1; #JMO
I learned a lot about references using this module, too.

2. Saving myself from the tyranny of Microsoft:
Spreadsheet::ParseExcel automates what would be a daily, very tedious task. (Don’t ask unless you are willing to buy me a beer in order to hear the story behind this.)

3. Automating version control:
CVS::Simple, which I’m in the process of replacing with Git::Wrapper. I’m learning git at the same time, so it’s quite a wild ride.

4. I’m writing tests, try not to faint:
Test::Most and Test::Mockobject

5. Enforcing coding standards:
Perl::Critic

6. Having fun at my co-workers’ expense:
Lingua::Bork. Pass the daily reports through this, and see who’s actually reading them.

7. And of course, DBI. Don’t leave home without it.

Update on some others I mentioned:

Cisco::Reconfig is still intriguing. I’ve encountered a couple of quirks and am trying to figure out if It’s Just Me ™ or they’re actual bugs.

Last time I worked with Net::MAC was v1.2, and I encountered what I thought might be a bug when iterating over an array of mac addresses. I didn’t need it for any heavy lifting (just converting macs to cisco format), so instead of filing a bug report, I stuck with my hand-rolled solution. The problem has been fixed in 1.5.

cvs has this nifty -I cli option, similar to the -I option to gnu diff – it allows you to specify a regexp and the cvs diff will ignore all lines that match that regexp.

Here’s a sampling of what I had:
cvs diff \
-I 'clock-period' \
-I '#time' \
-I 'set.spantree.port.*cost' \
[filename]


(Note that you can’t have spaces in the regexp you pass to cvs.)

git doesn’t have a cli switch for this; I was having a tough time figuring out how to make it use gnu diff. This gave me the tip I needed.

So, here we go!

0. If you don’t have gnu diff on your machine, install it. (I got mine from sunfreeware.com.) You can just run diff without any args to see the options – if you’re missing “I”, you don’t have the right diff.

1. Set up a wrapper script that uses gnu diff:
:::-->cat /home/gabrielle/bin/ciscodiff.sh
#!/usr/bin/bash
#make git use gnu diff and ignore certain lines
/path/to/gnu/diff \
-I 'clock-period' \
-I '#time' \
-I 'set spantree port.*cost' \
$2 $5 | cat

Notes:
- I don’t need the . instead of the space, like I did in the cvs regexp – so this is a more restrictive match. (Which I like.)
- $2 and $5 specify which of the parameters for git diff actually are passed through to this diff. See the “git Diffs” section of the manual.

Make sure to make this executable.

2. Then, back in my git repo, I added the following to .git/config:
[diff "ciscoconf"]
command = /home/gabrielle/bin/ciscodiff.sh

3. Then I created .gitattributes, like so:
*-confg diff=ciscoconf

git will now use my special diff wrapper *only* on files with names that match the *-confg glob pattern.

Voila.

First, install exuberant ctags if you don’t already have it.

Make sure it supports Perl:
:::-->ctags --list-languages | grep -i perl
Perl

Then, cd to the directory containing the modules you want to tag, and then create your tags file:
:::-->ctags *.pm

Too easy. There should be a new file called “tags” in that directory – check it out. All the subs that ctags found are listed here, along with the file it found them in, including duplicates (this could bite you in the ass if you’re not paying attention; see below).

Open up the Perl program you want to edit in vim. Load your new tags file with this command:
:set tags=/path/to/tags

Now when you find a questionable function, put your cursor on top of it & type ctrl-]. This will open up the module file & take you directly to the subroutine you’re looking for. (This is where having duplicate entries in your tags file could bite you – you’re going to get the first instance in the tags file.)

Navigate back to the original file with ctrl-t or :e#.

If you have a lot of files/subroutines, you may want something a bit more robust. I had about 20, spread over 5 modules, and about 30 programs that referenced them, so tracking them through this way didn’t take me too long.

Solaris 10 on x86. (uname -a: SunOS princess 5.10 Generic_125101-10 i86pc i386 i86pc)
git 1.5.6.2

Here’s what I had to do, gathered from various places around the web (the Makefile editing was gleaned mainly from http://discuss.joyent.com/viewtopic.php?pid=175313).

First, I had to install my own gmake, openssl, curl, and a couple of other required libraries.

Then:
./configure --prefix=/home/gabrielle/usr/local \
--with-openssl=/home/gabrielle/usr/local/include \
--without-tcltk \
--without-expat

Edit the makefile:
:::-->diff Makefile Makefile.orig
167,168c167,168
< CFLAGS = -g -O2 -Wall -I/home/gabrielle/usr/local/include
< LDFLAGS = -L/home/gabrielle/usr/local/lib
---
> CFLAGS = -g -O2 -Wall
> LDFLAGS =
172d171
< CURLDIR=/home/gabrielle/usr/local
891d889
< NO_ICONV=1

Make sure we're using gnu make:
:::-->/home/gabrielle/usr/local/bin/make -v
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-pc-solaris2.10

Then install like so:
/home/gabrielle/usr/local/bin/make INSTALL=/usr/ucb/install
/home/gabrielle/usr/local/bin/make INSTALL=/usr/ucb/install install

Voila doesn't really seem the appropriate thing to say here.

:grep [regexp] [file list]

vim will then load the files that match the regexp & position the cursor on the matching line.

use :cn and :cp to move between instances of the match.

This produces the easiest-to-read diff IMO:
diff -btu [oldfile] [newfile] > patchfile
-b = ignore blanks
-t = preserve source indentation
-u = 3 lines of context with the + and – in front of changed lines

But the -t option interferes with proper patch application, so just use:
diff -u [oldfile] [newfile] > patchfile
…where oldfile is the file you want to patch, and newfile is the file with the changes you want to apply.

patch -b -p0 < patchfile
-b = make a backup

If you are asked for the filename to patch – you probably don’t have the depth set right with -p.  Try increasing it.

If you get the message “Reversed (or previously applied) patch detected!”, somebody messed with your stuff between creating the patch & applying it, OR you did the diff backwards (common Monday morning mistake.)

In Perl, this is a no-brainer to me – the NULL value would be ‘undef’, and I could write something like:

$value = $default if (! defined $value);

So, after a bit of struggling, I found out that the ‘None’ object is returned when a value is NULL in python.

To determine whether you’ve got a NULL, you write something like:

if $value is None:
    $value = $default

Generally speaking, Python considers an undefined object to be a rare occurrence.