JavaScript training courses, jQuery training courses, C# training courses, ASP.NET training courses, and more to come!
-Jeff
Tuesday, September 7, 2010
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:
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!
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.
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.
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?
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?
Friday, December 12, 2008
Thinking usability
It's fitting that I would open this blog with what is probably the single-most important piece of advice I can give a software developer:
Build software for the user.
This may seem like a rather trivial piece of advice, but it's not. The farther you get into working on your product, the easier it is to forget that there are people who will be using your software who have never seen it before. And not only will they be new to your software, but they will also have plenty of other choices for software.
Now let's be honest here: As programmers, we know we were at the top of our classes throughout school and it's easy for us to feel like the people around us aren't always the brightest people on the planet. And it's easy to get frustrated and feel that if they're not understanding our software, then they're the ones with the problem.
But if they're not understanding our software and instead ditch it and pay for somebody else's software, then, in fact, YOU are the one with the problem--the problem paying your bills because the user who isn't very bright chose not to buy your product.
Of course, do you even want these people to use your product? If they're not very bright, do you want them to become a thorn in your side and constantly pester you for help?
And that's where it comes together: Of course you don't want them pestering you. But you do want them to use your software. And that's why you want to make your software clear. That doesn't mean it has to be dumbed down and easy to use, as if you're shooting for the lowest common denominator, coding for the guy who people wonder how he remembers to eat. Instead, you want to make your software straightforward and clear, and even obvious, without forcing the user to do extra work.
It's easy to find examples where people have screwed this up, especially on web sites. When I set up this Google account there were several places where I had to search the page for the button I needed. There's no reason for that. The layout should be clear. And think how many times you go to a website that requires a login, but once at the site you have to click again to get to the login page. That's unnecessary. The login should be right there on the main page. It's about being clear. Not dumbing it down, but being clear.
Remember, you're building a tool. The software is a tool, the connection between the user and what the user is doing. Right now I'm thinking about software, and I don't want to think about the page I'm typing this into. The page and its buttons are the last thing on my mind. It's me and what I'm doing (typing a blog) that's on my mind. Your tool should be invisible and not a constant headache to the user.
That's the first step. I'll be covering the groundwork in the days to come before we get into actual programming examples. The examples will be in various languages, because to the export programmer, the language choice should be no obstacle.
See you soon.
Jeff Cogswell
Build software for the user.
This may seem like a rather trivial piece of advice, but it's not. The farther you get into working on your product, the easier it is to forget that there are people who will be using your software who have never seen it before. And not only will they be new to your software, but they will also have plenty of other choices for software.
Now let's be honest here: As programmers, we know we were at the top of our classes throughout school and it's easy for us to feel like the people around us aren't always the brightest people on the planet. And it's easy to get frustrated and feel that if they're not understanding our software, then they're the ones with the problem.
But if they're not understanding our software and instead ditch it and pay for somebody else's software, then, in fact, YOU are the one with the problem--the problem paying your bills because the user who isn't very bright chose not to buy your product.
Of course, do you even want these people to use your product? If they're not very bright, do you want them to become a thorn in your side and constantly pester you for help?
And that's where it comes together: Of course you don't want them pestering you. But you do want them to use your software. And that's why you want to make your software clear. That doesn't mean it has to be dumbed down and easy to use, as if you're shooting for the lowest common denominator, coding for the guy who people wonder how he remembers to eat. Instead, you want to make your software straightforward and clear, and even obvious, without forcing the user to do extra work.
It's easy to find examples where people have screwed this up, especially on web sites. When I set up this Google account there were several places where I had to search the page for the button I needed. There's no reason for that. The layout should be clear. And think how many times you go to a website that requires a login, but once at the site you have to click again to get to the login page. That's unnecessary. The login should be right there on the main page. It's about being clear. Not dumbing it down, but being clear.
Remember, you're building a tool. The software is a tool, the connection between the user and what the user is doing. Right now I'm thinking about software, and I don't want to think about the page I'm typing this into. The page and its buttons are the last thing on my mind. It's me and what I'm doing (typing a blog) that's on my mind. Your tool should be invisible and not a constant headache to the user.
That's the first step. I'll be covering the groundwork in the days to come before we get into actual programming examples. The examples will be in various languages, because to the export programmer, the language choice should be no obstacle.
See you soon.
Jeff Cogswell
Subscribe to:
Posts (Atom)
Posts
