I personally recommend
the books shown to the right.

Tuesday, February 24, 2009

How to disable Javascript in Adobe/Acrobat Reader

1. Open up Adobe or Acrobat reader.

In Windows, there are several ways to do this; try the following:
  • Click the Start button in the lower-left of your desktop. Click All Programs. Scroll to the top of the list and find Adobe Reader. Click it.
  • If you don't see Adobe Reader, then try this: Click the Start button in the lower-left of your desktop.In the Start Search box, type Reader. Look for Adobe Reader in the list above to appear. Click it.
2. Once Adobe or Acrobat Reader starts, click the Edit menu at the top of the window. In the menu, click Preferences:



3. In the Preferences window, on the left side click JavaScript. Find the checkbox at the top called Enable Acrobat JavaScript. UNCHECK that checkbox:




4. Click OK.
5. Close Adobe Reader. You're done!

Tuesday, February 10, 2009

Geeks.com and SQL Injection

Before moving forward, I want to share with you a news item, and put it in perspective of our boot camp. A couple days ago, on February 5, 2009, Geeks.com agreed to a settlement with the FTC as a result of the site being hacked about a year ago.

What happened?

According to news sources, Geeks.com was hacked using a technique known as SQL injection; and once in, the hackers found the data was not encrypted.

SQL injection is incredibly easy to prevent. What happens when you're not guarding against it is a hacker will enter text into a web form; this text is intended to be used as part of an SQL statement. But the text being entered contains characters that terminate an SQL statement, followed by more SQL that accesses and modifies the data. (Note: This is a boot camp. Did that make sense? If not, read it again until it does. You're a programmer, and things like that should make sense to you.)

So how do you prevent SQL injection? Think about it. You don't want the characters that terminate an SQL statement to be allowed in; you don't want SQL in general to be allowed in. One way is to guard against such characters by deleting them or escaping them. Another is to not piece together the SQL but rather use stored procedures.

Now why does this relate to our boot camp? Because such errors should never have happened. It's hard to say what went on at Geeks.com. But I would like to speculate. This is my own speculation, and I can't know what really happened. But I would suspect it comes down to two problems: The programmers didn't know better, and the managers didn't know that the programmers were lacking in knowledge.

As programmers, we simply cannot allow this to happen. It's too easy to just put together code that works. But a good programmer must constantly be on alert for potential problems. Are you reading text from a web form and then piecing together a string into an SQL statement? Then what could go wrong? "What could go wrong?" needs to be constantly on our minds.

And even more, the programmers must be aware of the security risks and how to prevent them. "SQL Injection" is a common threat and you should know about it, and many others.

How do you find out about such things? The key there is to go to the online docs, the manuals, and read (or at least skim!) everything that you can. And most importantly, read the overviews and the "best practices" documents. Those documents will give you a summary of the most important aspects of what you're doing. And where do you find these documents? That's why it's vital to familiarize yourself with the documentation. Are you programming in PHP? Then know your way around the PHP.net site. Are you programming in ASP.NET? Then know the Microsoft documentation, both the one that's installed on your computer as well as the MSDN site.

That is key. As programmers, we must be masters of our trade, we must be experts, and we can not allow sloppiness to happen. Imagine writing code, thinking it's perfect, only to find out that due to one of your mistakes, the company is now being sued. Again, I can't know if that was what happened at Geeks.com, but I can say that if it does happen anywhere, it would be a horrible thing to go through. And there's no reason for it. Be an expert.

Wednesday, January 14, 2009

Knowing Your Resources

In the future installments of Programming Boot Camp, I'll be getting into hands-on programming, including code samples you can try out yourself. But for these first few sessions, I'm laying the groundwork.

Today I want to talk about the importance of knowing your resources. When you're developing software, the last thing you want to do is get stuck on a problem and spend days trying to fix it, only to find out there was, for example, an existing class and method already available in the library you're using that takes care of the problem. Or, for example, there might be a post on the Internet where somebody ran into the exact same problem and found a solution.

Now this may sound trivial, but it's not. Know your resources. Know how to find answers quickly.

Keep books handy. Keep a list of bookmarks. Know your way around the online help. If you develop in Visual Studio, for example, know your way around the huge documentation. (For example: I don't use the integrated help in Visual Studio. Instead I launch the help separately. I know how to quickly get to the docs for a class. I click on the Index tab and type the name of the class followed by the word class. I know that what I'll get is an overview of the class, and I know that at the top is a link for "Members". But I also know that in the index itself there will be a list of members. I've memorized that, rather than try to memorize the entire documentation itself.)

Know how to search the web. Know how to optimize your google searches. Read the online help pages for Google to find out how to do this. Know which sites keep programming samples and how to search those sites.

If you're a web developer, get the PDF of the official JavaScript ("ECMAScript") specification and know where it is on your hard drive. Put it in a Notes directory under your main development directory. (Mine is called c:\dev. What's yours? You do have one, right?) And speaking of the official specification, you do know where to find it online so you can save a local copy, right? Mine is on my drive, so I don't have the link. But I'll find it RIGHT NOW. Watch: Go to google. Type in ecmascript specification. It's the very first one that comes up. Done. Download it to your drive.

Some programming tools have additional features that will help you find answers quickly. Visual Studio and Eclipse both pop up information in the code editor while you're typing. Use these. If you've turned them off, turn them back on and learn how to get the most out of them.

Become a power user. I once had a coworker (a programmer no less) ask me to walk him through the steps of installing the Java JDK. Since this is a boot camp, I'm going to be blunt: Forget it, soldier. If you're scared to install the JDK, then what business do you have programming for the JDK? Get over your fears. Roll up your sleeves and install the damn thing. Set the environment variables. You should know how to do that on both Windows and Linux. (Learn both, even if you don't normally use both -- you never know when you may have to one day use the other, and you don't want to sound like an idiot on your first day on the job. You know how to "source a file" in Linux, right? If not, time to learn. You know what happens if you set your environment variables by running a batch command in DOS versus setting them for the whole system [and how to set them for the whole system], right? If not, time to learn. Go to Google and find out how. The answer is there.)

Know your resources. Know how to find answers QUICKLY.

Remember: Who gets promoted and who becomes the team lead first? The one who runs to others for help at the first moment of getting stuck or the one who the others come to when they're stuck?