February 2012 Archives

Steven James' CNN Editorial on sugarcoating the bible

I think that this in an interesting article. However, I think that the author is doing a little filtering of his own. He is filtering differences in translation through modern ears. Part of a good translation is not necessarily translating word for word. Try reading a translated poet like Rilke and you'll know what I mean. When translating, especially when translating the metaphorical or the ...poetic, you need to be able to find phrases that have the same impact and color as the original language.

"... let’s pretend Paul said that he considered his good deeds “a pile of garbage” in Philippians 3:8 rather than a pile of crap, as the Greek would more accurately be translated."

A great example, this. How do we know that in ancient Greek, the language Philippians was originally written in, saying "pile of crap" has as big an impact as on our Victorian principled ears. Language, sensibilities, and customs all change throughout the years. Last night, on regular broadcast TV I heard the word "shit" and really thought very little of it. Can you imagine hearing that coming out of Jack Tripper's mouth in the late 70s? Everyone would have been aghast and up in arms. Times and sensibilities change. Words change. Sometimes they gain impact, sometimes they lose it. Perhaps in Greek 60 A.D., "crap" had as much impact as "garbage" does today. I don't speak a word of Greek; modern or ancient, so I don't really know. But I do know that the author of this 'opinion' doesn't even mention the possibility.
To claim that we can't "edit" the Bible, or to "filter" it with modern sensibilities, the same has to be said for those who created the modern translations from the original scripts. Perhaps they actually knew what they were doing and used words that had the same "oomph." Perhaps the author was right and they sugar-coated the text to make it more palatable. I don't know, and I posit, neither does Steven James. If he does, he doesn't give evidence of it in this article.

A groan escapes the lips of every software tester every time he’s asked to write a test plan.  Some of us know what they are.  Some of us know the pain in the a$$ that they are to write. Some of us know that they need to be done. Some of us know that they consist of many different types of information.  But what we all know is the following:

After a test plan is initially written, almost nobody ever looks at it again.

But still, we all know that buried in the “Definition of Objectives,” “Schedules,” “Target Equipment Required,” and all the other bits & pieces of a “Good Test Plan” there lurks a few bits of useful information.

Going off on a rogue testing excursion may produce and find a few bugs (or maybe even a lot of bugs), but it’s not going to give you any sense of confidence that you hit all the major areas you need to test.  You do need to plan somehow.  How, then, do you avoid wasting time on a document that nobody is going to read, but still produce something useful?  

I’ve found that Mind Maps are extremely helpful, imminently logical, and almost universally useful for everyone involved.  It’s easy to pick up a mind map, follow the logical path of your thought process and either let you know you’re a genius or point out a few things that you might have missed.  Secondly, mind maps can double as your test cases as well. 

Take this example for example (click the image to view the whole thing):

While at first glance, it might look complicated, but when you take a moment and really look, you can see how it fits together and how it could be useful to you.  Best of all, this is something that you can go back to when it comes time for regression.  It becomes very easy to insert items that you may have missed and further, it’s something that other people in your organization will be able to understand.  Developers can use this to quickly determine if they’ve covered all the use cases, or better yet if you have.  Openness and transparency has been proven time and again to be the best policy for producing rock solid software. 

This mind map was produced with a piece of software called  XMind; though a piece of paper, a whiteboard, or even a wall might work as well for you.

I’d love feedback on this, feel free to drop me an email with questions, suggestions, or corrections.

Powershell makes doing math on Date object easier than falling down!

   1: $time = Get-Date;

   2: 

   3: ##Show Minutes

   4: $time.Minutes;

   5: 

   6: ##Show Day

   7: $time.Day;

   8: 

   9: ##Find out NOW stuff

  10: (Get-Date).Day;

  11: (Get-Date).Millisecond;

  12:  

  13: ##What Will the Date be 90 days from now?

  14: (Get-Date).AddDays(90);

  15: 

  16: ##What was the day 90 days ago?

  17: (Get-Date).AddDays(-90);

  18: 

  19: ## And for something practical

  20: $startTime = Get-Date;

  21: $endTime = Get-Date;

  22: "DONE in less than " + ($endTime.AddMinutes(1) - $startTime).Minutes + " Minutes";

As you can see, wonderfully simple.

When you are writing in the script window, you can access your execution history.  Simply type a comment hash character “#” and hit [TAB].  That will pull up the last item in your history queue.  Continue hitting [TAB] to traverse up the history queue as if you were in the command line window hitting the up arrow.