Easy. Quit making the mistakes that Internet Beginners make.
Bill Gates, AOL, Microsoft, Victoria's Secret, Gap, Coca Cola, and any other company you can think of, are never going to send you money for forwarding an email to fifty of your closest friends, so don't believe it if you see it. Likewise, messenger programs like Yahoo and AIM do not need you to forward a registration message to keep your account active and free.
Nothing cool is going to happen on your screen if you forward an email to fifty of your closest friends, no matter what that email says. Except that forty of those friends are likely to quit reading emails from you.
The damage done by forwarding virus alert emails is worse than the damage the virus would have done. Especially for the viruses that "will totally kill your system and ruin it for good by low-level formatting your hard drive and overclocking the CPU to ten times normal speed." And after that, those viruses will raid the fridge, leave the toilet seat up, and steal your girlfriend to boot. Leave virus warnings to the virus experts, keep your virus software up to date, and be careful what attachments you open.
Any email that asks you to visit a website and punch in personal information--like bank account numbers, PayPal passwords, and social security number--is false. This is called Phishing, and is one of the major methods of identity theft.
Any email from "HoTBabE DoWnToWn," claiming to be able to hook you up with a really hot babe tonight, was actually written by a 39 year old guy in his underwear who lives in his mother's basement. He's probably the same guy who wrote any email claiming to be from Pamela Anderson, Angelina Jolie, Anna Kuornikova, or your neighbor's wife and daughter. And any of those emails promising to show you all kinds of naughty nastiness will be glad to do so, but only after you punch in your credit card number and a promise to spend your beer, lunch, gas, and date money for the next 7.4 years.
Pop-up windows offering to remove spyware from your computer were probably generated by spyware that needs to be removed from your computer. Clicking on them will install yet more spyware on your computer, until the whole system is so bogged down with advertisements and tracking programs that it runs as fast as a Commodore VIC-20.
There is no one in Nigeria with millions of dollars in the bank. And even if there were, they wouldn't be screaming to share it with you.
If an email arrives with a handy-dandy link at the bottom that says "Click here to be removed from this mailing list!"...don't bother. They left out the part that is supposed to say "When you do, we'll be glad to remove you from this mailing list, but since you're letting us know that this email went to a real live person and not a junk mail folder somewhere, we're going to go ahead and sign you up for our other 79 junk mail lists AND sell your address to twelve other companies...in the hope that you'll actually respond to one of them someday." Instead, use an Email Filter to automatically delete any future emails from this spammer.
At the same time, if you visit a really cool website, and it has a handy-dandy link that says "just enter in the email addresses of all your friends so that we can show them this really cool site, too!"...don't. Treat email addresses like phone numbers; would you put your girlfriend's phone number up on a restroom wall? The amount of spam you whistle into your inbox is your own business, but when you start signing up all of your friends and neighbors to receive it too, you're just asking to be put on the "email pariah" list.
DON'T TYPE IN ALL CAPITALS...everyone will think you're yelling at them. DoN'T tYpe IN MiXEd CapITAls aNd LoWEr, unless you want everyone to think you're fifteen years old. And anyone you think is fiftteen years old is in reality undercover police hunting for perverts looking for fifteen year olds online.
And last, never EVER put magnets on your CDs and DVDs, because it might ruin them.
-=ad=-
Tuesday, January 31, 2006
Thursday, January 12, 2006
The Geek Brain: How to Think Like a Programmer
Here's a quick test to determine if you can think like a programmer.
You're driving down the freeway on your way to work, and your tire blows out. You wrestle the car out of the speed-demon's lane, through the daily commuter's late, and over into the granny driver lane, and pull off onto the shoulder. You see that the tire has shredded and needs to be replaced. You do all of the things that the average person does in this situation, like rant about the cost of replacement tires, curse about how late you're going to be to your second day of work, kick a big spray of dirt and rocks off the shoulder and into the desert, kick the tire, kick the car, and slowly cool off. It's now time to replace the tire.
What is the very first step in replacing the tire?
"Get on the cel phone, call the husband or AAA, and have them come and replace the tire." Hey, no fair, that's not in the spirit of the test!
"Oh, okay...*sigh*...umm...Remove the flat tire." Nope, wrong answer. The tire is firmly attached to the car.
"Raise the car to get the tire off the ground?" Um...it's kinda heavy, can't do that.
"Remove the lugnuts." What, with my fingers? They're on there really tight.
"Oh...get the jack and lug wrench out of the trunk." I can't, the trunk is closed.
By this point, the non-programmer is seriously peeved at all the wrong answers, and shouts "Open the *&^%&* trunk!!"
If this was your first answer, congratulations, you have the makings of a fine programmer.
Okay, so maybe it seems like a stupid example. But it does the job of explaining how a programmer has to think in order to design and develop his code.
What a programmer does is break a problem down into smaller and smaller chunks, until he reaches a level that a computer can do. To stick with the flat tire analogy, here's the "program" for changing the tire:
But, as we saw above, this doesn't quite work. We need to take this to a deeper level to get a step-by-step procedure, like this
Still, this doesn't give us the level of detail we need. This has to be broken down yet again:
This is now a set of directions that can be followed. This is our program, and since the "programming language" is English, this actually has a technogeek name: Pseudocode.
(The dirty little secret of the programming world is this: language is irrelevant. If you can pseudocode--that is, program in English--then you can program in anything. There will be a learning curve while you learn the idiosyncracies of each new language and syntax, of course, but most programs can be translated to another language with pseudocode and a reference manual. But I digress.)
Our example above even has some intermediate programming tricks in it. Notice the things that have to be repeated ("crank the jack until the tire is off the ground" and "for each lug nut"). In the language of computer geeks, these are called Loops.
A Do Loop is something that repeats until a goal is reached, like cranking the car off of the ground or sanding a piece of wood until smooth. Computers don't get bored, so it's easy to say "do it once, then check to see if it's done. If it's not done, start over again." The danger here is in getting stuck by using a sloppy goal ("Sand the wood once. Check to see if the wood is purple. If it's not, start over again."). There was a popular soft drink commercial that depicted this perfectly: "Insert dollar bill into the machine. Check to see if a can of soda popped out. If not, start over again." This is called an Endless Loop, because the computer gets stuck and can't get out of the process.
(Now you know why the old programmer joke is so funny. "Programmer found dead in his shower. He apparently tried to follow the instructions on his shampoo bottle and starved to death--Lather, Rinse, Repeat.")
What if you know in advance how many times you want the Do Loop to run? That's actually a different kind of loop called a For Loop ("For each of the five lug nuts"). In general, the concept is roughly the same, but instead of testing for a specific goal, you're just checking to see if you've run out of lug nuts.
And notice that the For loop ("For each lug nut") actually has a Do Loop within it ("Rotate counter-clockwise until the lug nut comes off."). This is a very common programming practice called Nesting. Nesting can get pretty interesting:
An Iteration is one trip through a loop. I wonder how many iterations someone could get through before getting arrested?
So, what have we learned today? We've learned that programmers take large problems and break them down into bite-sized chunks of pseudocode to solve them. We've learned that no matter what programming language is being used, it's still made up of a series of basic structures, like Do Loops and For Loops, chained one after another, or nested one inside another like a Russian wooden doll-within-a-doll.
And we have learned that almost any negative experience can be converted into a learning experience and a programming lesson, like the blowout I had on the freeway a while back.
-=ad=-
You're driving down the freeway on your way to work, and your tire blows out. You wrestle the car out of the speed-demon's lane, through the daily commuter's late, and over into the granny driver lane, and pull off onto the shoulder. You see that the tire has shredded and needs to be replaced. You do all of the things that the average person does in this situation, like rant about the cost of replacement tires, curse about how late you're going to be to your second day of work, kick a big spray of dirt and rocks off the shoulder and into the desert, kick the tire, kick the car, and slowly cool off. It's now time to replace the tire.
What is the very first step in replacing the tire?
"Get on the cel phone, call the husband or AAA, and have them come and replace the tire." Hey, no fair, that's not in the spirit of the test!
"Oh, okay...*sigh*...umm...Remove the flat tire." Nope, wrong answer. The tire is firmly attached to the car.
"Raise the car to get the tire off the ground?" Um...it's kinda heavy, can't do that.
"Remove the lugnuts." What, with my fingers? They're on there really tight.
"Oh...get the jack and lug wrench out of the trunk." I can't, the trunk is closed.
By this point, the non-programmer is seriously peeved at all the wrong answers, and shouts "Open the *&^%&* trunk!!"
If this was your first answer, congratulations, you have the makings of a fine programmer.
Okay, so maybe it seems like a stupid example. But it does the job of explaining how a programmer has to think in order to design and develop his code.
What a programmer does is break a problem down into smaller and smaller chunks, until he reaches a level that a computer can do. To stick with the flat tire analogy, here's the "program" for changing the tire:
1. Remove the old tire
2. Mount the new tire.
But, as we saw above, this doesn't quite work. We need to take this to a deeper level to get a step-by-step procedure, like this
1. Remove the old tirea. Jack up the car
b. Remove the lugnuts
c. Remove the tire
Still, this doesn't give us the level of detail we need. This has to be broken down yet again:
1. Remove the old tirea. Jack up the car--Open the trunkb. Remove the lugnuts
--Retrieve the jack and lug wrench
--Place the jack under the car
--Crank up the jack until the car is off the ground--For each lug nutc. Once all lug nuts have been removed, remove the tire.--Attach the lug wrench to the lug nut
--Rotate both counter-clockwise until the lug nut comes off
--Store the lug nut someplace safe so it doesn't roll away
This is now a set of directions that can be followed. This is our program, and since the "programming language" is English, this actually has a technogeek name: Pseudocode.
(The dirty little secret of the programming world is this: language is irrelevant. If you can pseudocode--that is, program in English--then you can program in anything. There will be a learning curve while you learn the idiosyncracies of each new language and syntax, of course, but most programs can be translated to another language with pseudocode and a reference manual. But I digress.)
Our example above even has some intermediate programming tricks in it. Notice the things that have to be repeated ("crank the jack until the tire is off the ground" and "for each lug nut"). In the language of computer geeks, these are called Loops.
A Do Loop is something that repeats until a goal is reached, like cranking the car off of the ground or sanding a piece of wood until smooth. Computers don't get bored, so it's easy to say "do it once, then check to see if it's done. If it's not done, start over again." The danger here is in getting stuck by using a sloppy goal ("Sand the wood once. Check to see if the wood is purple. If it's not, start over again."). There was a popular soft drink commercial that depicted this perfectly: "Insert dollar bill into the machine. Check to see if a can of soda popped out. If not, start over again." This is called an Endless Loop, because the computer gets stuck and can't get out of the process.
(Now you know why the old programmer joke is so funny. "Programmer found dead in his shower. He apparently tried to follow the instructions on his shampoo bottle and starved to death--Lather, Rinse, Repeat.")
What if you know in advance how many times you want the Do Loop to run? That's actually a different kind of loop called a For Loop ("For each of the five lug nuts"). In general, the concept is roughly the same, but instead of testing for a specific goal, you're just checking to see if you've run out of lug nuts.
And notice that the For loop ("For each lug nut") actually has a Do Loop within it ("Rotate counter-clockwise until the lug nut comes off."). This is a very common programming practice called Nesting. Nesting can get pretty interesting:
--For each car in the police station parking garage--for each tire on the car--next car--jack up the car--next tire
--for each lug nut--remove the lug nut--remove the tire
--put a block under the axle
--remove the jack
An Iteration is one trip through a loop. I wonder how many iterations someone could get through before getting arrested?
So, what have we learned today? We've learned that programmers take large problems and break them down into bite-sized chunks of pseudocode to solve them. We've learned that no matter what programming language is being used, it's still made up of a series of basic structures, like Do Loops and For Loops, chained one after another, or nested one inside another like a Russian wooden doll-within-a-doll.
And we have learned that almost any negative experience can be converted into a learning experience and a programming lesson, like the blowout I had on the freeway a while back.
-=ad=-
Monday, January 09, 2006
Database 101: In Databases, normal is GOOD!
Let's say you've got your E-commerce web site online, selling Wodgets. Mr. John Smith logs on, punches in his name as a brand-new customer "John Smith," and orders a month's supply.
When the time comes for Mr. Smith to order more Wodgets, he's in a hurry, and puts in a name of "J S" on the second order. And on the third, he's off on a business trip, and asks his girlfriend to place the order for him. She gets to the website, punches in his name, "J Smith," and the third order is shipped.
Now, you offer a special deal: "Any customer who's ordered at least three times from us gets his next order for FREE." (Hey, I never said my examples would be sane or logical!)
Our friend Mr. Smith is elated to hear this; it's time for his fourth order anyway. He leaps to the computer, punches in his name "John Smith" (the whole thing, this time there's free stuff involved, it's got to be perfect), and waits for the response.
The website searches the database, finds one match--the very first one--and reports back "I'm sorry, you've only ordered from us once, so you aren't eligible for this month's special."
"Stupid site," Mr. Smith complains, "I know I've ordered three times." He narrowly avoids putting his fist through the monitor out of frustration, and decides to order his Wodgets from a different supplier from now on.
So what went wrong? Why didn't the website understand that "John Smith," "J S," and "J Smith" were all the same person? The answer: Normalization.
Normalization is one of those database geek words, like Relational, Left Outer Join, and Whizbang, and it's used to describe a well-designed database. Normalized databases are idiot-proof...well, about as idiot-proof as a database can be, anyway.
Take phone numbers, for example. If you put a text box on your website called "Phone," how many different ways can a user enter a phone number?
Without area code: 123-4567
Without area code or symbols: 1234567
With area code: 899-123-4567
With extra symbos: (899) 123-4567
Here's the problem. When the database tries to do anything with all of these phone numbers, it's going to choke. It won't know that 1234567 is the exact same number as 123-4567. As far as the computer is concerned, these are two entirely different chunks of text.
If we Normalize, though, we can easily solve the problem. One way to do this would be to use three text boxes instead of one: Area code, then prefix, then suffix. The database can store these separately, or, more likely, the "save record" program in the website will merge all three together into one phone number to store in the database. All of the phone numbers will be stored in an identical format, and there won't be any confusion trying to pull the information out of the database. This same strategy can be applied in a bunch of different ways, like the Customer Name example above, or US States (Arizona, Ariz, AZ).
Normalization means protecting the database from the user by only allowing them to enter good data. To correct Mr. Smith's issue, a returning customer might be required to choose his name from a list rather than entering it fresh on every visit. That's actually a good idea across the board--the more places the user is required to pick from a list, rather than type in data, the better.
The key point with Normalization, though, is that it has to be part of database design--it can't be tacked on as an afterthought. You can tell if the database is not normalized if searches look like "If the state equals Arizona, or if the state equals arizona, or if the state equals AZ, or if the state equals az, or if the state equals Ariz..."
There's nothing more frustrating to a database geek than to be forced to deal with non-normalized data. "Oh, we had six different data entry people, and we just entered it any old way; can you fix it up real quick and merge it into the master database in the next fifteen minutes?" That's the kind of sentence that can lead database programmers into investing in mercenary magazine subscriptions and large ammunition collections.
There's more to Normalization than this, but this is the general idea. Keep it in mind as we explore other database topics, because it really comes in handy when design problems show up.
-=ad=-
When the time comes for Mr. Smith to order more Wodgets, he's in a hurry, and puts in a name of "J S" on the second order. And on the third, he's off on a business trip, and asks his girlfriend to place the order for him. She gets to the website, punches in his name, "J Smith," and the third order is shipped.
Now, you offer a special deal: "Any customer who's ordered at least three times from us gets his next order for FREE." (Hey, I never said my examples would be sane or logical!)
Our friend Mr. Smith is elated to hear this; it's time for his fourth order anyway. He leaps to the computer, punches in his name "John Smith" (the whole thing, this time there's free stuff involved, it's got to be perfect), and waits for the response.
The website searches the database, finds one match--the very first one--and reports back "I'm sorry, you've only ordered from us once, so you aren't eligible for this month's special."
"Stupid site," Mr. Smith complains, "I know I've ordered three times." He narrowly avoids putting his fist through the monitor out of frustration, and decides to order his Wodgets from a different supplier from now on.
So what went wrong? Why didn't the website understand that "John Smith," "J S," and "J Smith" were all the same person? The answer: Normalization.
Normalization is one of those database geek words, like Relational, Left Outer Join, and Whizbang, and it's used to describe a well-designed database. Normalized databases are idiot-proof...well, about as idiot-proof as a database can be, anyway.
Take phone numbers, for example. If you put a text box on your website called "Phone," how many different ways can a user enter a phone number?
Without area code: 123-4567
Without area code or symbols: 1234567
With area code: 899-123-4567
With extra symbos: (899) 123-4567
Here's the problem. When the database tries to do anything with all of these phone numbers, it's going to choke. It won't know that 1234567 is the exact same number as 123-4567. As far as the computer is concerned, these are two entirely different chunks of text.
If we Normalize, though, we can easily solve the problem. One way to do this would be to use three text boxes instead of one: Area code, then prefix, then suffix. The database can store these separately, or, more likely, the "save record" program in the website will merge all three together into one phone number to store in the database. All of the phone numbers will be stored in an identical format, and there won't be any confusion trying to pull the information out of the database. This same strategy can be applied in a bunch of different ways, like the Customer Name example above, or US States (Arizona, Ariz, AZ).
Normalization means protecting the database from the user by only allowing them to enter good data. To correct Mr. Smith's issue, a returning customer might be required to choose his name from a list rather than entering it fresh on every visit. That's actually a good idea across the board--the more places the user is required to pick from a list, rather than type in data, the better.
The key point with Normalization, though, is that it has to be part of database design--it can't be tacked on as an afterthought. You can tell if the database is not normalized if searches look like "If the state equals Arizona, or if the state equals arizona, or if the state equals AZ, or if the state equals az, or if the state equals Ariz..."
There's nothing more frustrating to a database geek than to be forced to deal with non-normalized data. "Oh, we had six different data entry people, and we just entered it any old way; can you fix it up real quick and merge it into the master database in the next fifteen minutes?" That's the kind of sentence that can lead database programmers into investing in mercenary magazine subscriptions and large ammunition collections.
There's more to Normalization than this, but this is the general idea. Keep it in mind as we explore other database topics, because it really comes in handy when design problems show up.
-=ad=-
Friday, January 06, 2006
What makes you think you can blog...?
I'm sure there are hundreds of new blogs started every day, and I'm sure every new blogger gets pounded with questions. Let me ask some of them for you:
"How can you call yourself a computer geek?"
Easy. I wrote my first BASIC program when I was in seventh grade, which was back in 19...well...more years ago than I'd care to admit. Let's just say that it was written on a Heathkit homebuilt TRS computer, and stored on a cassette tape, and leave it at that. I've taken some side-trips out of the computer world on occasion--I've been an aircraft electronics specialist, librarian, disk jockey, even cable puller and newspaper delivery--but I always seem to keep coming back to the digital world.
Got to be a screw loose in the logic circuits in my head somewhere, or I'm just a glutton for punishment...
In the computer world, I've built, sold, trouble-shot, repaired, installed, networked, cleaned, and yes, programmed computers, all the way back to the Apple IIc, Apple IIGS, and PC XT. (For those of you who never touched those systems, that was in the day when you were lucky to have 64 kilobytes of memory, not megabytes, and if you had a hard drive, you were one of the lucky elite!).
So, yes, I do feel qualified to call myself a computer geek, and am proud to wear the label. What's it to you?
"So, you're a geek with a blog. What's the point?"
There's one thing I learned, years ago, when I accepted my first computer tech job.
Geeks can't speak English.
No matter what the tech's skill level, they always seem to have trouble translating technospeak into English. Just watch the client's eyes glaze over while the tech explains why their system won't run correctly ("See, you've got this TSR program with a memory leak, and it's cross-indexing with the reserved memory used by your Winsock program, and the result is a buffer overflow error in your video ROM...").
I set out to make sure I didn't have that problem. In all the years I've worked in the computer world, I've always tried to develop a knack for explaining computer-ese into English. And this blog is the next logical step in all of that.
That's what makes me think I can blog...years of experience learning to translate geek to English.
The goal of Data, Demystified is just what it says--to make the technical, readable. Our primary focus will be database-oriented, with occasional forays into whatever other topics might arise; and the database explanations will be illustrated in MS Access or SQL. Comments and criticisms (and especially requests for help) will always be appreciated.
Thanks for stopping by, welcome aboard, I hope you enjoy the ride!
"How can you call yourself a computer geek?"
Easy. I wrote my first BASIC program when I was in seventh grade, which was back in 19...well...more years ago than I'd care to admit. Let's just say that it was written on a Heathkit homebuilt TRS computer, and stored on a cassette tape, and leave it at that. I've taken some side-trips out of the computer world on occasion--I've been an aircraft electronics specialist, librarian, disk jockey, even cable puller and newspaper delivery--but I always seem to keep coming back to the digital world.
Got to be a screw loose in the logic circuits in my head somewhere, or I'm just a glutton for punishment...
In the computer world, I've built, sold, trouble-shot, repaired, installed, networked, cleaned, and yes, programmed computers, all the way back to the Apple IIc, Apple IIGS, and PC XT. (For those of you who never touched those systems, that was in the day when you were lucky to have 64 kilobytes of memory, not megabytes, and if you had a hard drive, you were one of the lucky elite!).
So, yes, I do feel qualified to call myself a computer geek, and am proud to wear the label. What's it to you?
"So, you're a geek with a blog. What's the point?"
There's one thing I learned, years ago, when I accepted my first computer tech job.
Geeks can't speak English.
No matter what the tech's skill level, they always seem to have trouble translating technospeak into English. Just watch the client's eyes glaze over while the tech explains why their system won't run correctly ("See, you've got this TSR program with a memory leak, and it's cross-indexing with the reserved memory used by your Winsock program, and the result is a buffer overflow error in your video ROM...").
I set out to make sure I didn't have that problem. In all the years I've worked in the computer world, I've always tried to develop a knack for explaining computer-ese into English. And this blog is the next logical step in all of that.
That's what makes me think I can blog...years of experience learning to translate geek to English.
The goal of Data, Demystified is just what it says--to make the technical, readable. Our primary focus will be database-oriented, with occasional forays into whatever other topics might arise; and the database explanations will be illustrated in MS Access or SQL. Comments and criticisms (and especially requests for help) will always be appreciated.
Thanks for stopping by, welcome aboard, I hope you enjoy the ride!
Subscribe to:
Posts (Atom)