Welcome Guest!
 VB Helper
 Previous Message All Messages Next Message 
VB Helper Newsletter  Rod Stephens
 May 22, 2011 07:19 PDT 

Apparently yesterday's end of the world was somewhat overstated.

Things to do this week:

    - View screencasts

        Lesson 3, Part 1: http://www.youtube.com/watch?v=7jxlebRMuu0
        Lesson 3, Part 2: http://www.youtube.com/watch?v=GLGIFmvZx7E
        Lesson 5:         http://www.youtube.com/watch?v=xeJPTBTmNzA

        (I've gotten good feedback on these. Perhaps when I have some
time I'll post some more tutorials as screencasts.)

    - Post book reviews

    - Solve world economic crisis, end hunger and disease, achieve peace
Have a great week and thanks for subscribing!


Twitter feeds:

    Both Contents:
1. Another Cautionary Tale: Don't hide valuables in the trash
2. Cool Tool: .NET Reflector
3. The Joel Test: 12 Steps to Better Code
1. Another Cautionary Tale: Don't hide valuables in the trash

In the last newsletter I said, "This newsletter contains a cautionary
tale. (Hopefully I'll send another out soonish.)" After sending that
out, I realized it sounded like I had another precautionary tale, which
isn't what I meant. The world runs on irony, however, so the very next
day I stumbled into another harsh lesson.

A client of mine had a problem with a program I had worked on a few
months ago. After several hours of confusion, I found the problem was in
how they had configured the system. There were some other programs
missing that should have been running.

All was well but as I experimented with the program I noticed that it
didn't look like it was doing everything it should have been. After some
further study of the code, I found that this wasn't the most recent
version of the program I had worked on.

After much frantic searching, I found that the most recent code no
longer existed on that computer. That computer had previously been used
by one of the client's employees who later left and its code was just
sitting there. My contact was mad because someone had apparently deleted
the latest code.

His biggest complaint, and the main point of this story, is that he was
mad that someone had emptied the recycle bin. He reasoned he could
delete things to clean up the desktop but he would never empty the
recycle bin because space isn't an issue on that system. He uses the
recycle bin as a sort of archive for old material.

This doesn't sound like a best practice to me. You don't store your
china and best silver in a trash can at home because someone might throw
it out. Similarly you shouldn't store anything in the computer's recycle
bin because that means it's garbage. Being able to restore something
from the recycle bin is a feature that can save you if you realize you
shouldn't have deleted something right after you do so, it's not an
archive tool.

I'm pretty certain what happened was someone deleted the files (probably
my contact because I've seen him madly dashing around on the system
deleting folders that he didn't think were necessary without really
studying them closely) and then someone else emptied the recycle bin.

Now they're checking backups to see whether they have a copy of the
modified code. If they don't, I'll use .NET Reflector to disassemble the
executable, try to figure out what changes we made, and try to reproduce
them from an older code base. Not the absolute end of the world but a
big waste of time (and I don't have much time right now).
2. Cool Tool: .NET Reflector

This amazing tool, originally written by Lutz Roeder, can among other
things can disassemble a .NET assembly (exe or dll) and display Visual
Basic or C# code that might have generated the code. It can't tell for
certain what code generated the assembly, but it produces code that
could have done so and that you can study to figure out how the assembly

.NET Reflector was purchased by Red Hat and now you have to pay for it
(from $35 available at http://reflector.red-gate.com), although there's
a 14-day free trial.
3. The Joel Test: 12 Steps to Better Code


This is a quick test Joel Spolsky threw out to give you an idea of how
good your software organization is. Take the test very quickly. No need
to write anything down or get too detailed, just go with your first

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

If you didn't get an 11 or 12, you might need to look at your process.

The URL shown above gives commentary on the test's questions.

There are lots of other similar tests out there with generally the same
theme. There are also good books and you should definitely read a few.
One really good one is "Code Complete" by Steve McConnell. I highly
recommend it.

You can also check out my book "Bug Proofing Visual Basic"
(http://www.vb-helper.com/err.htm). It covers many of the same topics
but with a VB spin. It's out of print, which means I don't make any
money from it but it also means you can buy a copy for $1.06 at Amazon.
(No kidding! Out of print books such as this one that aren't
version-specific are a great way to save some money.)

Twitter feeds:

Post questions at:
 Previous Message All Messages Next Message 
  Check It Out!

  Topica Channels
 Best of Topica
 Art & Design
 Books, Movies & TV
 Food & Drink
 Health & Fitness
 News & Information
 Personal Finance
 Personal Technology
 Small Business
 Travel & Leisure
 Women & Family

  Start Your Own List!
Email lists are great for debating issues or publishing your views.
Start a List Today!

© 2001 Topica Inc. TFMB
Concerned about privacy? Topica is TrustE certified.
See our Privacy Policy.