A fine article Sunday in the PD regarding the 21-20 playoff win by Case over Widener. The Observer chimes in as well.
A remarkable 4th quarter with a 97 yard touchdown pass for Case to take a 15-14 lead midway through. Case would score 18 points in the 4th, with the final 6 coming after Widener scored with 1:27 left in the game.
After Widener missed the 2 point conversion, Case drove the field converting a 4th and 10 and a 4th and 13 before a 4th down with 7 seconds left at the Widener 7. They were able to convert and punch the ball into the endzone as Sophomore QB Dan Whalen completed a remarkable drive with a pass to Jeff Mayer.
This is not even close to the Case I remember...the last winning season they had was in 1991...when I was waiting to see if I would be able to get into school. I think they had four wins one year when I was there which was "huge".
Case won't be able to keep coach Debeljak for long if he keeps this up...but he is crucial because he "gets" Case. Stuckey sure didn't when he was there. Debeljak is clearly working within the system of Case and working to make sure his kids are prepared for the game as well as prepared for class. If Terry Pluto's (formerly of the Beacon Journal) column from Friday's Plain Dealer doesn't put into perspective the job Debeljak has done, then nothing will. This guy is coach of the year in D III. No doubt in my mind.
This week will be interesting for preparation for Wabash with the Thanksgiving holiday. There should be fewer tests and papers due at this point since finals are just around the bend. Wabash (a liberal arts college for men), likely does not have the same challenges in organizing practices around o-chem study groups and lab classes.
For those who were at the university in the early to mid 90s...you're likely as shocked as I am with the success. You're probably not quite sure how to say "Go Case!" because there was little reason to before...but what the heck....
"Go Case!"
Monday, November 19, 2007
Saturday, November 17, 2007
Wow, Case Wins!
I don't know if the video/audio will remain available at the University's athletic site in archive form (hint, hint...it needs to), but Case's 21-20 victory over Widener was shocking.
A team, no one expected to be in the playoffs, whose players were more concerned about O-Chem tests (love those weed-em out classes), goes out and takes case of business at home against Widener with a 2-minute drill drive at the end of the game to win.
Case takes on NCAC champ Wabash next week.
A team, no one expected to be in the playoffs, whose players were more concerned about O-Chem tests (love those weed-em out classes), goes out and takes case of business at home against Widener with a 2-minute drill drive at the end of the game to win.
Case takes on NCAC champ Wabash next week.
Wednesday, November 14, 2007
Using TestNG to drive "eyeball" testing
Second of my Best of Internal Blog (BoIB) series originally posted on 9/6/2007 and updated 11/14/2007
In my daily job, I do something that NBC would consider "green". I digress, but wasn't that an awful promotion last week? I help large companies save paper (and money) by presenting documents they would normally send to their customers through the mail. 99% of these documents are bills.
During my time working with various documents, I developed a tool based upon the testing framework TestNG. This tool allows us to look at a "cycle" of documents and test various things on each of them. We need to be sure that we're presenting each item to the user as it looks on their paper statement. It is most useful when we have a client who cannot generate an edge case test file for us due to the legacy nature of the billing system.
I had an opportunity to dredge it up again. The code for this tool is over two years old, but works relatively well with little fanfare. It grabs a list of identifiers from the database for each document, generates a URL to each document and then browses the HTML document using HtmlUnit. However, I recently found it has a new use.
The latest use is PDF testing. Some of our clients use a document format from IBM known as AFP. It's a high speed printer format, but it is similar to PDF in many ways in that it describes where on a page to display text. It is possible to generate a PDF document from and AFP document using a number of tools.
So how can the document tester help? Simple, create a special test class that is setup to archive the PDFs for each statement to disk.
Here's the test method inside TestNG (obviously I'm not repeating all of the bootstrappy type stuff that gets the URL to the document)
Pretty neat! Now you get a directory full of PDFs that you can archive and ship off to your customer, or browse yourself. It sure beats a manual process of click and reload, and assures a proper test of using the actual application to generate the document. You could obviously save HTML or CSV files as well, but they can be tested using classes within the testing tool, which is obviously more efficient. This is simply making "eyeball" testing a bit faster.
In my daily job, I do something that NBC would consider "green". I digress, but wasn't that an awful promotion last week? I help large companies save paper (and money) by presenting documents they would normally send to their customers through the mail. 99% of these documents are bills.
During my time working with various documents, I developed a tool based upon the testing framework TestNG. This tool allows us to look at a "cycle" of documents and test various things on each of them. We need to be sure that we're presenting each item to the user as it looks on their paper statement. It is most useful when we have a client who cannot generate an edge case test file for us due to the legacy nature of the billing system.
I had an opportunity to dredge it up again. The code for this tool is over two years old, but works relatively well with little fanfare. It grabs a list of identifiers from the database for each document, generates a URL to each document and then browses the HTML document using HtmlUnit. However, I recently found it has a new use.
The latest use is PDF testing. Some of our clients use a document format from IBM known as AFP. It's a high speed printer format, but it is similar to PDF in many ways in that it describes where on a page to display text. It is possible to generate a PDF document from and AFP document using a number of tools.
So how can the document tester help? Simple, create a special test class that is setup to archive the PDFs for each statement to disk.
Here's the test method inside TestNG (obviously I'm not repeating all of the bootstrappy type stuff that gets the URL to the document)
@Test(parameters = {"filePath"})
public void testGetPDF(String filePath) {
List formList = theDocument.getForms();
Iterator formIterator = formList.iterator();
// 1st Form gets the PDF
HtmlForm myForm = (HtmlForm) formIterator.next();
HtmlInput myInput = myForm.getInputByName("viewDocument");
try {
Page newPage = myInput.click();
WebResponse resp = newPage.getWebResponse();
ByteArrayInputStream pdfStream = (ByteArrayInputStream) resp.getContentAsStream();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
File pdfFile = new File(filePath + this.theDocumentID + ".pdf");
FileOutputStream fos = new FileOutputStream(pdfFile);
int count = 0;
int data = pdfStream.read();
while (data > -1) {
count++;
baos.write(data);
data = pdfStream.read();
}
baos.flush();
baos.writeTo(fos);
baos.close();
fos.close();
pdfStream.close();
} catch (Throwable t) {
org.testng.Reporter.log("Throwable: " + t.getMessage());
t.printStackTrace();
}
}
Pretty neat! Now you get a directory full of PDFs that you can archive and ship off to your customer, or browse yourself. It sure beats a manual process of click and reload, and assures a proper test of using the actual application to generate the document. You could obviously save HTML or CSV files as well, but they can be tested using classes within the testing tool, which is obviously more efficient. This is simply making "eyeball" testing a bit faster.
Subscribe to:
Posts (Atom)