Quick Update & 4Ghz E8200 stable on air

Long gone from the place I was at in my last post. I'm at a new place now, and things are going well. Main point of this post was this though:



I upgraded earlier this month and decided I'd see what I can do. It's very stable. I had it running for 48 hours stress testing with Prime9564bit on Windows Server 2008. I'm using air cooling but it's definitely not stock. Here is the full rundown of components other than the CPU:

ASUS P5K Pro
G.SKILL (2 x 2GB) DDR2 1066 (PC2 8500) 5-5-5-15
ASUS P5M2-8SB4W 80mm SuperFlo CPU Cooler
Vantec Tornado TD8038H 80mm Case Fan - I replaced the fan on the ASUS CPU cooler with this.
Arctic Silver 5 Thermal Compound

Motherboard Settings:
CPU Voltage: 1.36250
DRAM Voltage: 2.08
NB Voltage: 1.31
SB Voltage: 1.21
FSB Frequency: 500
DRAM Frequency: 1002 (Selected from the "Standard" clocking configuration option)

Doing QA Wrong

I've been working on some test code that originated from some of the other developers in support. I thought at first it had come from someone who had left a little over a year ago, but it turns out it did not. I wish I could say more, but I don't like saying much about people I have to work with if it isn't nice.

1. Using network locations for image sources and temporary storage.

Reason: This shouldn't require too much explanation. If there is no network connection, the tests won't work. If the machine the images are on is off, gets destroyed, goes down, crashes, etc, the tests won't work. If someone replaces one of the files due to some reason the tests won't work. The tests already require that one machine be in sane condition - adding another machine to that AND a network connection between the two when it's not necessary is just plain dumb. In addition to the basics, when you access resources across a network permission issues tend to arise. This is not something you want to deal with when simply running tests. The test code itself should not be able to fail easily.

What I Do: All test code is in source control. I keep files used by that code under the same tree the code is in. This means that baselines and test files are also in source control (as they should be). I usually call this folder TestFiles. Under that folder I keep two more folders: SourceFiles and VerificationFiles. Source files would be the location for source images, or any other file that is used in a test. Verification files is where I keep all files that are used to compare with the output of a test for pass determination. This allows for really simple running of the test code. Source control also allows for many benefits in this scenario. If a file changes then there should be a comment as to why it changed. We can see what about a file changed because we still have both versions. Unwanted overwrites and corruption are also prevented in this scenario.

2. Saving files used in comparisons to hard coded paths (or saving anything to a hard coded path really)

Reason: You can never really be sure that a hard coded path will exist on a system. Especially C:\. Not only that, but writing files to the root of C is just a really bad idea for a number of reasons. If you use the same hard coded path for output files, and run more than one test, the second test that uses that file is invalid. This is because the file exists in the first place, so if the line in the test that outputs the file is skipped, the test either still has a chance to pass, or will fail for unknown or strange reasons. Assuming that you are testing that a component is outputting a file, this is exactly what you want to prevent in your test code.

What I Do: I always use the windows GetTempFileName and GetTempPath api or their environment's equivalent when outputting temporary files. This can create an issue where temp files build up on a system, so it is necessary to ensure that the files are removed after the test completes. This requires a little more work than hard coding a path, but the test quality you achieve as a result is definitely worth it.

3. Not testing the result of an operation

Reason: I really don't think I need to explain this. I was REALLY surprised to see code like that in the tests. Code that literally did nothing but call a function. The test makes sure the function doesn't throw an error or make the suite crash. <THICK SARCASM>Oh yeah, that's really useful!</THICK SARCASM> That's like manually testing if MS Word can open a file by going to file:open, selecting the file, hitting accept, and doing nothing more. If the dialog goes away the test passed. Whether or not it actually opened the file is not tested - there is no verification that there's anything on the screen. It's just testing that it looks like you can open a file. That's a useless test!

What I Do: Verify the output of the call/method or verify that the property has the right value. The method is supposed to do something, so check the things it was supposed to do. I really don't think I need to go more in depth here.

4. Use 1 Error handler that only says the test failed.

Reason: This provides very little information to the developer or even the tester. Without any more detail this gives us no information on why the test failed. This means that someone will have to step through the entire test to find the line of code that it failed on. This does not mean there has to be an error handler for every line of code though.

What I Do: In VB (COMUnit) I try to use an error handler for every method that outputs the error number and description. That's all that is really needed there. For .NET, use ample try/catch blocks, and give valid descriptions for your assertions and exceptions. This isn't hard - it's just that people can be really lazy sometimes.

5. Not thinking about what the test is really doing

Reason: This has a specific case to accommodate it. There was a test that was outputting a color image, in memory, that measured 50in x 30in x 300dpi on a 32bit machine. The test never passed. The test never will pass. It is impossible to fit that image into the data type that it was being output in. The requirement was ridiculous, and no one had taken the test out.

What I Do: Make sure what the test is doing is sane. No reason to test things that can't be tested. No reason to test absurd things.

6. Checking that an output file is correct by making sure is is greater than a hardcoded number of bytes.

Reason: I shit you not that this code was in there. It outputs a file, and asserts that it's greater than the "baseline file size". The baseline file size is 4000. I really don't need to go into further depth as this also falls under other categories.

What I Do: When testing files against baseline files I have a set of methods I use depending on the file type and one method for generic files. Length is asserted to be the same for both files first, then they are opened and tested byte by byte. When there is a byte difference, the location in the file where they differed is in the test error/exception. Simple.

7. Using reserved words for labels/names/variables (On Error GoTo error)

Reason: If you need to ask, you need to take an introduction to computer programming course.

What I Do: I don't use reserved words for variables, names, or labels. Simple.

8. Using Assert True or testing a condition then raising a failure

Reason: First, using a constant true in the expression will never issue the message. A good compiler will even take the line out completely. Why the code was there in the first place simply shows me that the original coder has no idea what they are actually doing. The assert statement's expression is the conditional. Adding more code to issue a failure on a conditional is counter-productive. It is bad to add useless code.

Example Bad Code:

Assert(True, "This message will never ever show.");
If (someCondition)
Assert(False, "There was an error");

Proper Code:
Assert(someCondition, "There was an error");

Some of these issues seem absolutely ridiculous to me. I almost cannot believe I found code like this here. What's worse is that it won't be fixed any time soon because it would take too much time, and the people are working on other things. If I find anything else I'll add it here...

PECompact2 Codec Tester

For testing your own PECompact2 codecs
Something I whipped up to test one I was doing for a personal project. It leaks memory, but it's really only meant for simple testing. It only does one layer codecs too. No guarantees, have fun!

download here

Creative Spam

Don't leave the toilet seat up!!!

SUCH NONSENSE!

Using the restroom:
Courteous man Process for #1:
a) Is the seat down?
b.Yes) Lift seat up
c) aim.
d) fire away.
e) Place seat back down.

Courteous man process for #2
a) Is the seat down?
b.No) Place seat down.
c) place ass on seat.
d) fire away.

Women's procedure is the same for #1 and #2. According to women who complain about men and toilet seats, this process is:
a) Place ass on whatever is there
b) fire away.

So, in essence, women who complain about the toilet seat being left up are simply lazy because they don't want to take an extra step that they should already be taking. Add to this that men aren't always courteous, they can miss sometimes, and the occasional splashing and you're left with assurance that at some point you will sit down in a nice puddle of urine.

Proposed procedures for fairness across sexes and no complaints:

Proper man Process for #1:
a) Is the seat down?
b.Yes) Lift seat up.
c) aim.
d) fire away.

Unisex process for #2, and female process for #1
a) Is the seat down?
b.No) Place seat down.
c) place ass on seat.
d) fire away.

Projects that go both ways - Unicode and Not

Allowing a project to support Unicode when programming with C++ in a Microsoft Windows environment can be tricky to those who haven't touched the subject. Here I'll break down the basics, and will go over some simple rules.

When using strings in your code, don't use the type char; instead, use TCHAR. Additionally, types like LPSTR will have a T inserted to indicate a TCHAR - so they will turn into LPTSTR. This type is redefined depending on whether your project is set to use Unicode or not. Formatting normal strings for this type should be enclosed in a TEXT(). Function calls using this type should be preceded with _tcs instead of str.

The macros you should learn are TEXT, _TEXT, _T, and L. _TEXT, _T, and TEXT will convert a string to the appropriate type depending on the project settings/preprocessor definitions. They will all automatically convert ASCII strings to valid Unicode ones when Unicode is defined. _T and _TEXT are literally the same thing, although TEXT is slightly different. TEXT uses the UNICODE preprocessor definition instead of _UNICODE. I honestly am not sure at this point what impacts that could have - more research is needed. L will convert the string to Unicode always.

For an example, use VS2005 to start a new Win32 Console application with default settings - except include common headers for ATL. VS2005 sets a project to default to using Unicode, so it's a good thing to use to observe how things should be done. Once the project is created, we can already see that the main function is actually called _tmain, and that the parameter for the command line arguments if of type _TCHAR *.

Let's enter some code into our main function so that we can see what is happening. Declare a TCHAR array and set it to a string, using the TEXT macro to format the text. Next, print the string using _tprintf. Finally, call MessageBox with the string as either the caption or the text. The body of your main function should look something like below.

TCHAR myNewString[] = TEXT("Hello There!\n");
_tprintf(myNewString);
MessageBox(0,myNewString,TEXT("Some Text Here"),MB_OK);

Run the project, and you will see the output. It's exactly what you would expect. Change the project settings to change between multi byte, Unicode, and none. You'll see that no matter what you choose the project compiles and runs as you would expect.

Place a break point at the MessageBox line and set the project settings to Unicode. Start debugging the application. When it breaks on the MessageBox line, look at your watches, locals, or autos for the address that the string you created is being stored at. Open up a memory view (Debug:Windows:Memory:Memory x). Enter the address for the string. You will see that in memory, each character of your string is taking up two bytes of memory. You'll notice that none of the extra bytes has a value of anything other than 0. This is only because we used ASCII characters and ASCII characters are the first set in Unicode. If you set the project to none or multi byte you will notice that the string is a normal one byte per character ASCII string.

Still confused? Yeah, I am a little too, oh well ;-P

Wisdom Teeth and Evolution

http://www.livescience.com/animals/top10_vestigial_organs-1.html

The number 5 is "Wisdom Teeth"

<Pull from http://www.livescience.com/animals/top10_vestigial_organs-1.html>
Wisdom Teeth in Humans

With all of the pain, time, and money that are put into dealing with wisdom teeth, humans have become just a little more than tired of these remnants from their large jawed ancestors. But regardless of how much they are despised, the wisdom teeth remain, and force their way into mouths regardless of the pain inflicted. There are two possible reasons why the wisdom teeth have become vestigial. The first is that the human jaw has become smaller than its ancestors' and the wisdom teeth are trying to grow into a jaw that is much too small. The second reason may have to do with dental hygiene. A few thousand years ago, it might be common for an 18 year old man to have lost several, probably most, of his teeth, and the incoming wisdom teeth would prove useful. Now that humans brush their teeth twice a day, it's possible to keep one's teeth for a lifetime. The drawback is that the wisdom teeth still want to come in, and when they do, they usually need to be extracted to prevent any serious pain.
</Pull>

People exist that were born without wisdom teeth. I only know two people with this condition though, a friend of mine from highschool, and me.

Go Evolution, GO!

VB vs C#

The bottom line in my opinion is this:

When you learn the syntax of C, you are learning the syntax of C, C++, C#, Java, and JavaScript.

When you learn the syntax of VB, you learn the syntax of VB.

Things I hate

1. People who use the word jaded... especially in a description of themselves.
2. Hypocrites... I love pointing out the hypocrisy though.
3. Liars... Even the smallest lies are unnecessary.

My Ongoing Words...

It's hard to accurately use the words "never" and "always" because you'll never find that it's always the case!

Less than one percent of the world increases their knowledge and intellect with each passing day, while the rest continue to have intelligent thought escape them at seemingly increasing velocities.

You know, the kind of place that has a breakfast buffet, but gives you 7 forks.

People are quick to speak their mind, but are slow to think about what they are saying.

I've tried to reason with them, but for unexplainable reasons, I'm incapable of reasoning with unreasonable people.