Firefox and the Enterprise Environment

Firefox recently updated to version 5, and sent Firefox 4 to the EOL graveyard.  It plans to do the same with Firefox 6 in 6 weeks, and Firefox 7 6 weeks after that.  Enterprise IT staff are in a tizzy because their internal testing takes that long to figure out whether a piece of software will work for them, and the rapid release schedule completely destroys their system for testing.  See this quote from Mike Kaply's blog by John Walicki to get the idea.

I have 500,000 corporate users on Firefox 3.6. We just completing a test cycle of Firefox 4 on many thousands of internal business web applications. Many hundreds of application owners and their test teams have participated. We gave them several months to ready themselves. We worked with dozens of internal Add-On developers and product teams to prepare their add-ons for Firefox 4. We’re poised to deploy Firefox 4.01 in 3Q when the corporate change freeze lifts. Education programs, documentation updates, communications all are planned. While several of us keep up with Aurora, I can’t expect thousands of app owners to do the same. I applaud the effort to accelerate the pace of Web experience and I expect to chase version releases well into the future. The Firefox 4 EOL is a kick in the stomach. I’m now in the terrible position of choosing to deploy a Firefox 4 release with potentially unpatched vulnerabilities, reset the test cycle for thousands of internal apps to validate Firefox 5 or stay on a patched Firefox 3.6.x. By the time I validate Firefox 5, what guarantee would I have that Firefox 5 won’t go EOL when Firefox 6 is released?

Asa Doltzer responded that he would do the opposite and guarantee that when Firefox 6 is released, 5 will go EOL.

I understand John's (John works for IBM in their IT department) concerns with regards to internal testing and the test version they used being no longer supported by the time they roll it out.  I just think there's an easier solution than trying to force Mozilla back to their earlier versioning scheme. Currently Mozilla puts out 3 to 4 branches for public use. These are:

Full Release: The standard releases you're all familiar with. The most stable release. Currently on version 5.

Beta: A familiar name for a familiar concept.  Pulled from the Aurora branch shortly before being pushed out as the next Full Release.  Currently not available.

Aurora: The perpetual beta branch.  Aurora is pulled from Mozilla Central and is where UX and new feature work takes place.  If something isn't ready that's in Aurora when Beta is set to be branched, it gets disabled and pushed back to the next release. Not the most stable, but not the least.  Currently on version 6.

Mozilla Central (Nightly): Mozilla Central is the trunk of the Firefox dev tree.  Most work gets done on Moz Central, and every night the first build to pass their automated test suite is pushed out as the Nightly release.  Inherently the least stable.  Currently version 7.

Based on this information, my advice to enterprise level IT staff:  Start testing Firefox Aurora, and follow it through until it hits Full Release.  Yes, there will be some changes to Aurora while you're testing it, but all those changes are publicly available on bugzilla, and are fairly easy to collate into a single list for you to keep an eye on.  Watch for changes that have an effect on you or your tests, so that you can time your rollout of Firefox with when it hits Full Release.

MS Access 2007 and VBA

Today was an interesting day at work.  My boss is on a camping trip for today and tomorrow, so I'm the only IT person here, which means I get to answer everyone's stupid questions!  It wasn't that bad, I only had 1 stupid question, and spent the rest of my day helping out a coworker with the Access Database he's building for Project Management.  His first request was for me to come up with a method for Access to automatically schedule a task in Outlook.  Given that I haven't done much VBA  I reluctantly agreed to help, and spent the first hour of my day figuring out how to turn on the Outlook reference in the Access VBA environment.  After that it was all trial and error as I tried and failed and tried and failed to successfully scrape the information I needed out of an Access form.  I finally got it, and about a half hour after I sent the results over to him he comes back wondering why he can't use strings to set the body and subject of his tasks.

I walked him through step by step and worked through it on my copy of his database with him guiding em through what he did.  As soon as we got to the part where he was calling his strings in the NewTask.Subject line, his problem became crystal clear.  He preceded every string call with str, which he should if his strings start with str, which they should if he followed common programming/scripting practices, but he didn't, and as a result they didn't and his code broke because he was calling strings that weren't there.

I thought that would be the end of my troubles with him, but it turns out I was wrong of course.  He returned a third time, asking about why he couldn't assign a task to himself.  This one, like the first one, was actually a problem.  Since I wasn't listed as a user or contact in his database, I never was able to thoroughly test whether or not I could assign a task or not (I used NewTask.Display, which pops up the Outlook dialogue and allows you to adjust any of the imported options before assigning a task.  It also let me cancel before I assigned because I have enough tasks as it is).  Sure enough, you cannot 'assign' yourself a task, outlook has a different dialogue for that.  So now he had a 2 part task for me.  1) find a way to get the logged-in users username and compare to their name in the database, and 2) use the appropriate task dialogue depending on if you're assigning to yourself or not.

Part 1 was fairly easy, I found a chunk of code <a href="http://access.mvps.org/access/api/api0008.htm">here that works beautifully for this</a>, and just made a module for it.  Part 1.5 involved some string functions, because the username scheme we use being first-initial-last-name means that Full names and usernames are totally different.  Conversion to lowercase, grabbing the first character then searching for the position of a [space] and grabbing the characters after that fixed it so they could be compared to one another.  Now to figure out the difference between Assigned task and a regular self-assigned task.  After some playing around it was apparent that the NewTask.Assign call was at fault for converting the tasks to an assigned task, so moving that along with the contact lookup into the If/Then/Else statement solved that problem.

All in all, I'd say today was a rather productive day for me.