A little over a year ago I became the supervisor of a web development team for the State of Utah.  My team's primary set of projects includes responsibility for the Unemployment Insurance (UI) portion of the state's web site.  If you are an employer you can pay your UI taxes, or file your wage and new hire reports online.  If you are a UI claimant/recipient you can file your claim and file your weekly job search report online.  In fact, if you have an uncomplicated claim you can file for unemployment insurance with out ever picking up a phone or going into an office to talk to a claims taker.

Innovation Award

A while back we started a project with another team to try and save the state, and by extension the Utah taxpayers, a substantial amount of money by delivering UI correspondence electronically.  After a few technological bumps in the road the project has been a huge success.  We are on pace to save over $1.4 million a year in printing and mailing costs on a project that cost well under $100,000 to design and implement.  This project was nominated for and won a U.S. Department of Labor Unemployment Insurance Innovation Award.

Bad Business Reporting

They say that any publicity is good publicity, and we got some press in the local paper.  Unfortunately the headline is terrible and the reporting isn't much better.  "Utah agency honored for e-mail use to help jobless" makes it sound like we are just sending emails to people - we've been doing that for almost a decade now. Our project actually creates an online repository of any correspondence sent back and forth between us and our customers.  If you hand-write a note that gets scanned and stored digitally and you will have access to that online.  If there is a decision on your case the decision letter shows up in your correspondence inbox and you are sent an e-mail notifying you of the new document.

I am really proud of the work that my team did on this project. Don H., Justin M. and Ken S. deserve special recognition.  Don did the bulk of the user interface development, Justin keeps all the web services and image servers running, and Ken built a number of complex Oracle stored procedures and batch jobs to process all of the documents.  Congratulations guys.

(This post is from my old blogger site - thought it was time to move it here for safe keeping.)

Several months ago we began to transition from an in-house logging framework to Log4Net in our primary web applications. For the last couple of days I have been trying to troubleshoot some production problems in the two of these applications and I noticed that my Log4Net logs were using a 12hr clock for the timestamp, and didn't include an AM/PM indicator. It also used old style parameter names rather than the newer verbose parameters.

Seeing as how I tend to cut and paste code for things like that, and I know other programmers do as well, I figured I would blog about what I am switching to, as well as a couple of other options. In case you are not really familiar with log4net, this setting is changed by editing the value string for the ConversionPattern param in the - log4net --appender - section of the web or app config file:

<param name="ConversionPattern" value="your string here"/>


The old:
value="%-5p %d{yyyy-MM-dd hh:mm:ss} - %m%n"
Results in:
ERROR 2008-12-03 01:28:38 - login.aspx submitted for 7234

Besides the timestamp problem, the format string is difficult to understand. It is not at all obvious what 'p', 'd', 'm' and 'n' stand for. Well, maybe the fact that 'd' is followed by a date format string you could guess that it stood for Date.

The following link lists both the shortcut and the verbose fomat values from the Apache log4net documentation.

The one I am switching to:
value="%-5level %date{yyyy-MM-dd HH:mm:ss} - %message%newline">

Note the more obvious setting names. This value string results in:
INFO 2008-12-11 14:06:59 - login.aspx submitted for 7234


Other choices:
value="%-5level %date{G} - %message%newline">
Results in
INFO 12/11/2008 2:15:07 PM - login.aspx submitted for 7234

value="%-5level %date{yyyy-MM-dd hh:mm:ss t} - %message%newline">
Results in
INFO 2008-12-11 02:06:59 P - login.aspx submitted for 7234

value="%-5level %date{G} - %message%newline">
Results in
INFO 12/11/2008 2:15:07 PM - login.aspx submitted for 7234

value="%-5level %date{u} - %message%newline"
Results in (not this is UTC time)
INFO 2008-12-11 14:06:59Z - login.aspx submitted for 7234

Those of you familiar with date string formats in the .Net framework will recognize some of these strings. The Log4Net framework allows you to use any date format that is valid in a ToString() call in the .Net framework. For additional format strings see the MSDN Format String Documentation.

I have been converting a number of test classes from NUnit to the Microsoft Test Framework (MSTest).  There are a number of quirky differences between the two, but the one that got me last night was how to use module-level variables.

Frequently in NUnit you (or at least I) use [TestFixtureSetup] to set module level variable (like connection strings) eg.

[TestFixture]	
public class AreaDAOTest
{
     private string _myVar;

     [TestFixtureSetUp]
     public void Init()
     {
         _myVar = //whatever here...;
     }

This doesn't work in MSUnit because [TestClassInitialize] is required to be a static and can't set reference variable.

The two options I tried were to use [TestInitialze] or a test class constructor. [TestInitialze] is run every test as expected, but what we didn't expect was that the constructor seemed to be called for each test as well.

The better pattern, discovered by a co-worker (thanks, Paul) for setting module level variables is:

[TestClass]
public class AreaDAOTest
{
     static string _myStaticVar;

     [ClassInitialize]
     public static void TestSetup(TestContext MSTestContext)
     {
          _myStaticVar = //whatever here...;
     }

On one of the primary web applications I maintain we have real-time help available to clients through an online chat application.  Usually when one of the chat line workers gets an interesting bug report they IM me and I try to fix the problem.

For weeks now I have occasionally been getting questions about our date validation. Specifically, we have people entering today's date and getting told that the date they have to enter must be today or earlier.  We have about 35 places where you can enter a date and the business requirement actually is that the date entered be 'today' or earlier.  We validate this on the server side, but also on the client using the JavaScript function show below.

//Validate Past date

//---------------------------------------------//

function validatePastDate (control, sFieldName) 

{

    var c = document.getElementById(control);

    if (c != null ) 

    {

    //validate hasDate and isDate snipped//

        var d = new Date();

        var now = new Date();

        if(d.setTime(Date.parse(c.value, "n/j/y")) > now) 

        {

          sErr = sFieldName + " '" + c.value + "' must be a date earlier than today. \n"; 

        }

    }

    return sErr;    

}

 

Since the bug was opened in our issue database four different testers have tried to replicate it and none have been successful.  Yesterday I got pinged on IM and told that the 'funny date thing' was happening again.

I dropped everything and decided it was time to fix this once and for all.  I poured over the code, looking at the function and everywhere it was called.  No luck.  I ran it from my development box and from the beta server.  No dice.  I fired up an ancient desktop box that was kicking around and all of a sudden...ERROR!

Then I looked in the bottom right hand corner of the screen and noticed that it was 3:06 AM.  Bingo!  When I double-clicked the clock I discovered that the system date on that computer was 4/1/09, not 4/6/09.  It's clear now, but we all overlooked that

 

var now = new Date(); 

would report the client's system time to the client side validation...

I typically find myself using the Window Search all the time. It does a great job of finding files and documents by name, filtering the criteria by date or size, and I like having results in the graphical file explorer where I can sort by several attributes. If it could find my keys at 5:30 in the morning it would be the primary function on my laptop.

My recent experience with Search has been less satisfactory. I recently inherited several thousands of lines of HTML, asp, VB 6 and JavaScript code in hundreds of files that makes up a major portion of my employers web site. At the same time our database admins rolled out a new version of one of our primary databases that serves as a back end for several desktop and web applications. Unfortunately the web site wasn't checked thoroughly for dependency on the old database, nor compatibility with the new one. (That should be a topic for a whole separate stream of posts.)

Needless to say, this week has been one composed of frantic scrambling trying to figure out what was up and what was broken, and why. In a little bit of serendipity, I found that most of the applications used one particular configuration file in which was stored the connection information tagged with a label like 'ORA_CONNECT' (Nice job, previous developers.) When an application needed to connect it would call to the root config file and get the connection information by passing the label. Pretty standard stuff.

So, my first thought was to use the Windows Search to see if I could find all files that contained the string "ORA_CONNECT". So navigated to the root directory, fired up search, entered the parameters and waited with eager expectation after clicking on search. A long list of files came up, but shockingly it did not include the three files I had looked at by hand to determine what connection was being used.

Puzzled, I set up a little test. I created a directory with two subdirectories. In the root I put a text doc, and in the subdirectories I placed an HTML, ASP and MS Word file. Each file included text that contained the string ORA_CONNECT.

I ran search on that directory, and it found everything EXCEPT the use in the ASP page. I even went back and made sure that the All Files and Include Subdirectories options were enabled. Clearly Search was not reliable.

What will I FIND

I IM'd a co-worker about what I was tying to do, and he sent me a string using the FIND command. Ah Ha! Good old find! I had forgotten that since the last time I spent hours writing MS-DOS 5 batch files years ago. Oh No! Bad FIND...


As you can see from the image, access was denied to the subdirectories. FIND does not recurse. I knew I could write a batch to recurse the directories, and save the output to a file, etc, etc; but who has that kind of time?

FINDSTR /i /s ss64.com *.*

It was then that I remembered reading somewhere that there was a 'find' in windows that supported regular expressions like grep. I quick check of my links turned up the excellent site ss64.com - a command line reference site for SQL Server and Oracle, which just happens to have an XP/NT section.

The page on the FINDSTR command had just exactly what I needed:

Check out the command reference on ss64.com for other options, like printing the line and line number that match, and outputting the results to a text file.

This post was originally published on geekcyclist.blogspot.com on 10/5/2007

Welcome to the new AgileCoder.Net blog.

 Over the next few weeks I will be moving the technology related posts over here from my old blog at geekcyclist.blogspot.com.

 Please stay tuned!