One year later...

I wrote this a year ago, and have not recovered.

Angela M. Reichert - My Wife

My wife, Angela Marie, she was born July 20, 1963 at Camp Pendleton in San Diego. She married me on September 12, 2003. This only after I chased her down for a year and half. During that time she was my best friend. Even though we both dated others, we both talked about each other too much to our dates. Then at the beginning of summer of 2002, she decided that I was the one she had been needing, not just wanting, like the others (much her own words.) We got married at my parent's house. It was what she wanted.
Now for the sad apart.
Even before we got married I knew of the extent of her health. With her life style and the problem with her pancreatic; there was little hope. But she had no one else who would care for her. Our marriage was grand. We would go exploring various place around the Pacific Northwest that neither one of us had ever seen. Never to venture to far for a hospital in case she had an issue. Oh, yes, she would need to go the hospital about twice a month on the average. Her illness continued for over 6 years. each years she got worst. After we moved to Memphis she lost contact with her child (from her previous marriage). It appeared that the children (Elizabeth and Tyler) were led to believe that their mother did not love them. This was a lie. She love them more then live it self, more even me. A lie, to prevent them from attempting to contact her directly. Strange, the same thing happening to Angela when she was young, when her mother left her with her step-dad.
I feel that the move to Memphis was a mistake for all of us; her, me, her children, even my family too. Well, Jan of 2008: one morning she awakens me and shows me that her stomach was swollen. This was strange. Here a lady that weighed less then 90 pounds to have stomach that made her look like she was 6 months pregnant. We went to our family doctor (name withheld), and he quickly diagnosis that she was simply malnutritioned. So we went home. A few days later, after following the doctors instruction (with she also felt she knew best, and the doctors were quacks - after as many as we have seen I did not blame her.) we when to the ER. She was in the hospital for around a week then released. She still looked the same. They were following our PCP diagnosis. This was a Saturday (I believe). Then after a few more days at home and the problem did not seem to be getting any better, I took her back to the hospital. This time we force the doctors look outside box by not tell them any of her past medical conditions. By doing this they determined that her lever was failing. They removed nearly a gallon of puss from her lever. Unfortunately it was to late. Had they diagnosed it week to two earlier she may have had a change (yes, if the PCP or previous hospital visit.)
The HARDEST thing I have had to do was to tell her she going to die and there was nothing to prevent it. I stayed with her. On January 28, 2008 at 11:42 pm I felt the life leave her.

DAMN I MISS HER.

As I write this I cannot help but cry. After crying for the last 4-5 years I guess I am in titled to morn now (yea, tell my ex-boss that.)
I ask to anyone who reads this to say prayer. She had a hard life and I truly believe that every thing she did was in helping other unselfishly.

And for anyone interested in see some pictures of our wedding.

Query

I have just recently posted version 2.0 of my Query tool. What is Query? It allows Visual FoxPro developer use the SQL language to Select, Update, Delete, and Insert into most any form of listed data. Data source like Array, Collection, SQL Server tables, VFP Tables and Cursors, the file system of files, and list goes on. Not only are these data source available, but you add your own data source.

One of the coolest is that when querying a data sources, there can be different types of dasta sources in the same SQL statement. Here is an example of a Query request.



Query([SELECT * from table Customers ] ;
+ [LEFT JOIN SQL Orders CONSTRING lcConStr ON Customers.CustID=Orders.CustID ] ;
+ [ Where City in (Select Exp1 from Collection Cities) ] ;
+ [ ORDER BY CustID ] ;
+ [ INTO XML OBJECT CustOrder.xml ]



Here we are grabbing rowes from the local table of Customer, and joining with a SQL Server table of Orders, and using a collection to filter the result; which is saved to a XML file. How many lines of code would take normally to preform the same act.

You can download the tool from my web site at http://www.GLRsoftware.com/Download.asp#Query.zip

A few Debugging tips

Recenting , while I was debugging a FoxPro application I discovered a few tricks.

The first trick was when attempt to write a Intellisense code. I found tha the SYS(2030) would revert to disabled when the Intellisense code is called. So, I placed in the Debugger Watch window the statement SYS(2030,1). Therefore forcing the value of the SYS() function to be Enabled with each line that is executed. This allows for the debugger to trace the intellisense code I wrote.

The second trick was having Timers on my form. When I have a object in the Watch window. And I expand it to see the properties, the Timer would fire, and the object would collapse. To solve this annoying problem I would either place the state thisform.SetAll("Enabled",.F.,"Timer") in the Watch window, or execute at the command window. This forces all the timer to turn off.

Late Binding of Objects

VFP 6.0+


After seeing the “My” object introduced to VFP 9.0, I decided to write a similar object for accessing many of the functions of FoxPro and windows called System.prg. In my first attempt, I encapsulated the FoxPro functions of SYS() and SET() to allow better readability. For example, Instead of the coding as SYS(3), the object version would be oSystem.UniqueName(). This helps make my coding more understandable. Well, after a while, I added other FoxPro functions like HOME, OS, VERSION, and etc. As the number of methods grew, so did the object. After a while, the time it took to instantiate the object grew also. Now recent I added methods that accessed the operating system using Win API and WMI queries. This was cool, but it was adding several seconds to the start up of my application. Something had to done to speed up the creation of the objects. The solution was not to create the individual object until they are accessed for the first time. The following snippet of code demonstrates how this is done.

loObject = CREATEOBJECT("MainClass")
? loObject.FirstObject.FirstMethod()

DEFINE CLASS MainClass as Container

FirstObject = .NULL.

PROCEDURE FirstObject_access
this.FirstObject = IIF(ISNULL(this.FirstObject), ;
CREATEOBJECT("FirstClass"), this.FirstObject)
RETURN this.FirstObject
ENDPROC

ENDDEFINE

DEFINE CLASS FirstClass as Container

PROCEDURE FirstMethod
RETURN "Hello World"
ENDPROC

ENDDEFINE

If we step through using the debugger, you will notice that after loObject is created, the property FirstObject is NULL. But when execute the second line in attempt to call FirstMethod, the FirstObject_Access method is called first, therefore creating the object for first. Then the method FirstMethod called afterwards. With several dozen objects, and hundreds of methods, this means of delaying the creation of the object until they are needed speeded up the startup of the application.

You can download the latest copy of this class here

LifeCycle - Build Phase 1.0 has been released.

Over the past couple of years, I have been developing (and refactoring) the LifeCycle - Build Phase utility. This utility is an advance Visual FoxPro build utility, designed to run build scripts against full project solutions (multiple projects). I designed the utility to be very flexible and extendable. The user can design multiple types build scripts (build styles), and schedule them to be preformed at set times and intervals (via Scheduled Tasks). These build scripts are made up individual tasks, stringed together like lines in a program. The tasks themselves are simple Visual FoxPro Class methods, freely distributed in a Tasks folder. I encourage others to design and develop additional Tasks that can be shared with other LifeCycle - Build Phase users.

The version you receive is compiled in Visual FoxPro 6.0, and has been test successfully in all later versions (6.0 to 9.0).

You can read more about this exciting new utility at http://www.GLRsoftware.com/LifeCycle.asp. You can download the free Light version here at Universal Thread download area (download #28218), or directly from my web site at http://www.GLRsoftware.com/Download.asp#LifeCycle.exe.

The initial download is free (Light version), but has limited features. But for a small fee, these limitation can be removed and transform the utility into a full feature version (Professional version).

Thanks, and please either reply to message with questions or concerns, or email me at LifeCycle@GLRsoftware.com

Greg Reichert

GLR Software - www.GLRsoftware.com

The life cycle of a bug

Recently I wrote a paper for the company I am currently working for. It was titled "LifeCycle of a bug". Its intent was to educate the testers and developers in the company to write better bug reports. For you see, I would receive bugs with statements like "Found a bug in hte Employee data enter", or "System crash and I could not add anymore". And these would come from the
developers. While, as I said, I wrote the following paper, and felt like sharing it with you all.

---

LifeCycle of a Bug

Writing and submitting software bugs.

Overview

The purpose of this document is to provide a consistent and workable method to submit a bug, track its progress, and resolve it with the most minimal problems.

If you feel to elaborate on this document to better refine it, please feel free to do so. But please, initial you contributions.

What is a Bug?

First, let clarify what a bug is.

A bug is any abnormality in the software (or hardware) that either prevents a process from completing successfully, or behaves out side of scope of the specification or users experience (job wise), or appears incorrect (spelling errors).

It is my experience that it is not the testers place to determine if the abnormality is an actual bug or not. This is why a Triage team is created and assembled to evaluate submitted bugs to determine not only if they are if fact a bug, but how and who will handle them. I like to think of the tester as the Software Cop, and the Triage team as the Judges. The Cop writes the ticket, and Judge determines if a crime was actually committed.

How to write a complete and clear bug report

When an Issue (bug or enhancement) is submitted, the following point must be included: What (description), where (placement in the application), when (version and build number), and how (steps to reproduce), why (expected result) and finally, how was it resolved. Too often I have been assigned an issue and only the most vagueness of these points is met. If I can not reproduce the issue, I can not know if it fixed. These kinds of issues are general sent back the source for better clarification. But let us take a moment and clarify these points to better understand them.

What is the issue (Description)

This is not only the caption or summary of the issue, but also a long explanation of the issue found and placed in the Description body of the issue. It should provide enough information to give the triage team and developer a general understanding of the issue and its severity.

Where in the software was the issue found.

Like the description, this provides help to determine how the issue will be handled. It helps classify the issue into categories; like the module, form, or even the level in the application structure.

What version/build was the issue found, and fixed. (When)

It is important that not only what version was the issue discovered in, but also what build. Sometimes a bug will creep in starting at a single build. Once again, it can not be reproduced; the developer may just pass it back as irreproducible. But in fact they were looking in the wrong build. If the application contains multiple platforms, all with their own version and build numbers, when in doubt included them all. This is true with our system where there is an EAF version, and Inform version, Metadata version, and even a client side version. Try to keep track of which version the application is using.

For the developer, place the version and build number the fixed code will appear in to the issue when resolving it. This aids the tester in being sure that they are testing the correct version and build.

Steps to reproduce the issue (How)

The steps to reproduce the issue are perhaps the single most import part of submitting a bug. If the developer can not reproduce the bug on call, he/she can not find and fix the bug, nor can they unit test to validate the bug to be fixed. The same is true for the tester that gets the issue assigned to them to validate the bug is in fact fixed.

The Steps to Reproduce section should be very detailed steps. The steps should take the user (developer) from a known position to the actual point the problem occurs or can be observed. The steps are layed out in a numerical outline, for example.

1. Open Inform Standard. Notice the application name.

2. Login as yourself with password. Notice that login level is mentioned.

3. Observe that the current logged in user is you. This will help the developer understand the severity later in the steps.

4. From Welcome page, logout. Notice the page name is mentioned.

5. At the “Log Out Confirmation” page, click “Log In” button. The step may appear ambiguous, but mention it anyway.

6. In the Login ID field, type in the Administrator login. Observe the change login level is mentioned. This is to help emphasize the severity of the issue.

7. Press Enter (do not click the submit button). Notice that this emphasizes the action of the user not to use the mouse.

8. Observe that the current user is now the Administrator. This procedure allows any user to login as administrator level without a password. When stating the resulting problem, emphasize the severity of the problem.

Always validate the steps before committing the issue. If you can not reproduce the problem, how do you expect anyone else to be able to?

Expected result (Why)

It is always best to place an Expected Result section into the body of the Description portion of the issue. Sometimes the users (tester) expectation is not within the scope of the application, or has not been considered, and therefore the issue is more of an enhancement then a bug. The expectation should clear enough to relate the expected outcome.

How was it fixed? (Risk)

When the developer fixes the bug, they should always place a comment as to how it was fixed and where. This should not necessarily be technically detailed, but a enough to help the tester be able to verify the problem is resolved, and that know other risk area are effected.

Other points to have in the issue

Of coarse there many other points that is relative to classify an issue. Here are a few of them:

Project: Name of the Project

Customer: Customer that reported the problem

Status: Open or Closed

Priority: Low, medium, high, or blocker

Severity: Low, medium, high, or crash

Estimated Time to fix:

Related Issues: Any other similar issues

Attachments: Screen shots or code snippets.

Date Opened:

Date Resolved:

Date Closed:

Conclusion

Quality Assurance, Testing, and problem resolving is the last line of defense between success and a client dropping a buggy product. Personally, I would rather have a tester discover the problem then the customer. Testers get paid to find bugs, customer pay to find bugs. Who would be helper to find a bug?

---

I hope this helps others to report better bugs to the develepment and QA teams.

Newbie to this kind of stuff.

Well, here I am. I never was much for writing my thoughts so that everone could read them. But I guess I need to get into the 21 century.

As one of the unemployed IT specialist, I have a lot of time on my hands. So I should spend some of the time expressing my feelings, and providing some ideas to others.

For those that are interested, I have web site that is mainly deticated to the Visual FoxPro developer. But, recently, I have attempting to spaned it into other areas of interest. Here is the URL. http://www.glrsoftware.com/

All are welcome to visit my site and provide me with any feedback they like.