June 28, 2007 by mensming.

A week and a half ago, I ended a nearly seven year run at Varolii Corporation (formerly PAR3 Communications). I enjoyed my work there and I value the friendships I made. I am confident that the company will be successful and I recommend it for anyone looking for a job in the Seattle or Boston job markets. See the jobs page on the Varolii website for current openings.

My new position is at a company by the name of SiteScout Corporation. We are an early stage startup. While we are keeping the details of the business model under wraps, one of our taglines is “Making the Web safe again.” As a startup, my role will be wide and varied — which I am looking forward to.

While it is hard to say goodbye to Varolii, I am excited to say hello to SiteScout.

Posted in personal | No Comments »

June 13, 2007 by mensming.

I recently completed an overview of web security testing for my team. Below are the links I used as resources. I consider the OWASP Testing Guide to be the most useful.

Posted in security, web testing | No Comments »

June 9, 2007 by mensming.

With a note of panic, I received the message that svn update had thrown away a developer’s changes. He had attached a log showing the commands he had issued. Sure enough, instead of seeing a merge, the file was updated and his changes were gone. The only thing not in the log I wish was there was a svn status command.

I was concerned but not overly worried. Since we converted from CVS to Subversion, there had not been any major issues. No one else had reported these problems. Obviously, if this were a bug in Subversion, it would be all over the web. There was something here that was missing in the description. I needed more details. I arranged a meeting to investigate.

What we discovered was enlightening and led us to a better understanding of how Subversion works. After discussing the situation, below is what we discovered had happened. For the purpose of the description, “Developer A” is the person who reported the issue. “Developer B” is another person on the team.

Developer A and Developer B’s working copies are both at revision N.

Developer A commits a change. (His working copy is now at revision N+1.)

Developer A and Developer B discuss and agree that the change needs to be rolled back.

(It is a little fuzzy here what happened. However, the essentials are correct)

Developer A “undoes” his change manually but does not commit the change. (His working copy is still a revision N+1.)

Developer B updates his working copy (now at revision N+1). Developer B issues the reverse merge command to undo the change introduced by Developer A. Developer B commits the change. (His working copy and the repository are now at N+2.)

(Time passes…)

Developer A and Developer B discuss and realize that the original change (committed at revision N+1) does need to be made.

(Here is where the confusion occured)

Developer B (whose working copy is still at revision N+1 while the repository is at N+2) starts to work on the change. Without updating his working copy, he reintroduces the change manually and does a svn update

At this point, svn “throws away” Developer A’s change.

If you are familiar with Subversion, you already know why. If Developer A had issued the following commands, he would see what happened:

(Working copy at revision N.)

Make changes.

svn commit

(Working copy at revision N+1.)

Manually undo the changes.

svn status filename
(The command indicates that filename has changed from the base revision - N+1)

Manually redo changes.

svn status filename
(Indicates no change in the file. Even though it has been changed twice since the last commit, it is now identical to the file at the time of the last commit in this working copy.)

svn update filename
(Subversion checks to see if the file is different from the base revision - N+1. It isn’t. No merging of changes need to be made. Go ahead and update the file to the state it exists at revision N+2 thus “throwing away” the changes the developer had introduced.

Posted in source code control | No Comments »

June 5, 2007 by mensming.

With the upgrade to Firefox 2.0.0.4, I immediately noticed a change on the companion site to this blog, www.meesqa.com. Prior to the Firefox 2.0.0.4 release (and in current IE versions), the links looked like this:

After upgrading to Firefox 2.0.0.4, the links look like this:

My CSS file for the links looked like this:

a:link{
background: inherit;
border-bottom-width: 2px;
border-color: #000000 #000000 #000000;
border-left-width: 0px;
border-right-width: 0px;
border-top-width: 0px;
color: #000000;
font-weight: bold;
text-decoration: underline;
}

The page and the HTML both validate.

Just commenting out the CSS entries for the links results in the site looking better but with default link behavior. Better, but not what I want. It appears that the line background: inherit; causes the issue. Removing all of the references to this line results in the pages displaying correctly in Firefox 2.0.0.4 and earlier and displaying correctly in other browsers.

Posted in web testing | No Comments »

June 3, 2007 by mensming.

Our CVS to Subversion conversion is complete. Now, we are in the process of settling into new working habits and learning the differences between CVS and svn. One of the questions last week was why do I not see the all of the changes when I run svn log?

Luckily, I had anticipated this question. cvs log will display all of the log messages for a file in both the trunk and all of the branches. svn log will display the log messages for the current code path. You will not see changes in branches that are unrelated to the history of the file. There is a command line option, --stop-on-copy, that will stop the log messages at the point where a branch was created. This change in behavior is a welcome change and most people find it intuitive.

Unfortunately, this was not the issue that inspired the question. The developer wanted to know why he did not see a change he knew had been checked in. cvs log would show the change by default. What I discovered was that the developer had not done an update in his repository. By default, svn log does not show revisions after the state of the current repository. This feels non-intuitive to me and was something I did not expect. You can get a full log (including changes made after the last update) by using the -r option.

Posted in source code control | No Comments »