Category: Developing with CSS3 for Dummies

I always recommend that you download the source code for my books. The Verifying Your Hand Typed Code post discusses some of the issues that readers encounter when typing code by hand. However, I also understand that many people learn best when they type the code by hand and that’s the point of getting my books—to learn something really interesting (see my principles for creating book source code in the Handling Source Code in Books post). Even if you do need to type the source code in order to learn, having the downloadable source code handy will help you locate errors in your code with greater ease. I won’t usually have time to debug your hand typed code for you.

Depending on your platform, you might encounter a situation the IDE chooses an unfortunate place to put the source code you want to save. For example, on a Windows system it might choose the C:\Program Files folder (or a subdirectory) to the store the file. Microsoft wants to make your computing experience safer, so you don’t actually have rights to this folder for storing your data file. As a result, the IDE will stubbornly refuse the save the files in that folder. Likewise, some IDEs have a problem with folder names that have spaces in them. For example, your C:\Users\<Your Name>\My Documents folder might seem like the perfect place to store your source code files, but the spaces in the path will cause problems for the IDE and it will claim that it can’t find the file, even if it manages to successfully save the file.

My recommendation for fixing these, and other source code placement problems, is to create a folder that you can access and have full rights to work with to store your source code. My books usually make a recommendation for the source code file path, but you can use any path you want. The point is to create a path that’s:

Easy to access

Allows full rights

Lacks spaces in any of the path name elements

As long as you follow these rules, you likely won’t experience problems with your choice of source code location. If you do experience source code placement problems when working with my books, please be sure to let me know at John@JohnMuellerBooks.com.

If you follow the trade news for even a few weeks, you begin to see a recurring pattern of security breaches based on web application deficiencies, social engineering attacks, or some other weakness in the security chain. The latest attack that is making the rounds is the IRS security breach. However, I’m not picking on the IRS, you can find security breaches galore in every arena of human endeavor simply by performing the required search. Everyone gets hacked, everyone is embarrassed by it, and everyone lies through their teeth about the methods used for the attack, the severity of the attack, and the likelihood of dire results. The attacks serve to demonstrate a simple principle I’ve written about in HTML5 Programming with JavaScript for Dummies, CSS3 for Dummies, and Security for Web Developers—if someone wants to break your security, they’ll always succeed.

Later analysis of the IRS attack brings out some important issues that you need to consider as part of your development efforts. The first is that you really do need to expend the effort to create the most secure environment possible. Many of the successful attacks use simple methods to obtain the desired result. Training really does help reduce social engineering attacks, updates really do help close security issues that a hacker can use to access your system, good programming practices keep hackers at bay, make applications easier to use, and reduce errors that result in security issues. All of these methods help you remain secure. However, remaining vigilant is important too. Monitoring your application and the libraries, APIs, and microservices on which they depend are all important. Despite protestations to the contrary, the IRS probably could have done more to prevent the breach, or at least mitigate the results of the breach.

A focal point of the analysis for me is that the IRS currently has 363 people working security and a budget of $141.5 million to ensure your data remains safe. The author is a bit harsh and asks whether the IRS Commissioner Koskinen thinks his people are stupid because he keeps making the claim that these hackers are quite skilled. Yet, the hacks used are really quite simple. Breaches happen to every organization at some point, no matter how much money you want to throw at the problem. Organizations get blindsided because hackers attack from a direction that is unexpected in many cases or the organization simply isn’t keeping track of the current threats. Again, I’m not heaping insult on the IRS, simply pointing out a problem that appears common to most of the breaches I read about. What is needed in this case is a frank admission of the facts and a whole lot less in the way of excuses that simply make the organization look weak or stupid anyway.

The IRS, like many organizations, later came back and increased the tally on the number of individuals affected by the breach. This is another common issue. Instead of investigating first and speaking later, many organizations provide numbers at the outset that really aren’t based on solid facts. When an organization has a breach, the public does need to know, but the organization should wait on details until it actually does know what happened.

The application that caused the breach is now dead. It’s a demonstration of a final principle that appears in many of my books. If you really want to keep something secret, then don’t tell anyone about it. Breaches happen when data is made public in some manner. Yes, it’s convenient to access tax information using a web application, but the web application will be breached at some point and then the confidential details will appear in public. Organizations need to weigh convenience against the need to keep data secure. In some cases, security has to win.

The more I read about security breaches, the more convinced I become that they’re unavoidable. The only way to prevent data breaches is to keep the data in a closed system (and even then, a disgruntled employee could still potentially make a copy). Being honest about data breaches, providing the public with solid facts, and ensuring remediation measures are effective are the only ways to control the effects of a data breach. Let me know your thoughts on this issue at John@JohnMuellerBooks.com.

The problems with ActiveX are many. The simplest of these problems is that ActiveX only works with Internet Explorer and only on Windows and Macintosh systems. The limitation means that ActiveX really doesn’t have a place with modern application development where everything has to run everywhere. However, even with this limitation, ActiveX is a security nightmare because it’s literally an invitation for anyone with any sort of code writing savvy at all to invade your system. Because these controls have complete access to your system (they don’t run in a sandbox), a hacker exploiting them can literally do anything and get by with it. Even Microsoft spent a good deal of time telling you how to protect yourself from the security issues that come with ActiveX control use. In short, using ActiveX controls are a truly horrid idea.

Unfortunately, Edge won’t be available for Windows 7 and older versions of Windows, so you know that those older versions of Internet Explorer will hang around forever. Given the security risk that ActiveX represents, you’d think Microsoft would want to save itself some trouble and make Edge available for everyone. Consequently, even though ActiveX is eventually going to go away, don’t look for it to die immediately. Let me know your thoughts on Edge, ActiveX, and the potential problems with older versions of IE at John@JohnMuellerBooks.com.

There is a myth among administrators and developers that it’s possible to keep a machine free of viruses, adware, Trojans, and other forms of malware simply by disconnecting it from the Internet. I’m showing my age (yet again), but machines were being infected with all sorts of malware long before the Internet became any sort of connectivity solution for any system. At one time it was floppy disks that were the culprit, but all sorts of other avenues of attack present themselves. To dismiss things like evil USB drives that take over systems, even systems not connected to the Internet, is akin to closing your eyes and hoping an opponent doesn’t choose to hit you while you’re not looking. After all, it wouldn’t be fair. However, whoever said that life was fair or that anyone involved in security plays by the rules? If you want to keep your systems free of malware, then you need to be alert and scrutinize them continually.

Let’s look at this issue another way. If you refused to do anything about the burglar rummaging around on the first floor while you listened in your bedroom on the second floor, the police would think you’re pretty odd. More importantly, you’d have a really hard time getting any sort of sympathy or empathy from them. After all, if you just let a burglar take your things while you blithely refuse to acknowledge the burglar’s presence, whose fault is that? (Getting bonked on the back of the head while you are looking is another story.) That’s why you need to monitor your systems, even if they aren’t connected to the Internet. Someone wants to ruin your day and they’re not playing around. Hackers are dead serious about grabbing every bit of usable data on your system and using it to make your life truly terrible. Your misery makes them sublimely happy. Really, take my word for it.

The reason I’m discussing this issue is that I’m still seeing stories like, “Chinese hacker group among first to target networks isolated from Internet.” So, what about all those networks that were hacked before the Internet became a connectivity solution? Hackers have been taking networks down for a considerable time period and it doesn’t take an Internet connection to do it. The story is an interesting one because the technique used demonstrates that hackers don’t have to be particularly good at their profession to break into many networks. It’s also alarming because some of the networks targeted were contractors for the US military.

There is no tool, software, connection method, or secret incantation that can protect your system from determined hackers. I’ve said this in every writing about security. Yes, you can use a number of tools to make it more difficult to get through and to dissuade someone who truly isn’t all that determined. Unfortunately, no matter how high you make the walls of your server fortress, the hacker can always go just a bit further to climb them. Headlines such as “Advanced Attackers go Undetected for a Median of 229 Days; Only One-Third of Organizations Identify Breaches on Their Own” tell me that most organizations could do more to scrutinize their networks. Every writing I read about informed security is that you can’t trust anyone or anything when you’re responsible for security, yet organizations continue to ignore that burglar on the first floor.

There is the question of whether it’s possible to detect and handle every threat. The answer is that it isn’t. Truly gifted hackers will blindside you can cause terrifying damage to your systems every time. Monitoring can mitigate the damage and help you recover more quickly, but the fact is that it’s definitely possible to do better. Let me know your thoughts about security at John@JohnMuellerBooks.com.

The world where users sit in front of a desktop system all day managing data is going away. Users won’t settle for just sitting in front of a computer any longer—they want to compute using their smartphone, tablet, and any other device that comes to mind. A time is coming when a user who has an idea in the middle of the night will talk to the alarm clock, which will make the required changes while the user goes back to sleep. For today, however, users appear content to make their changes using the interesting array of technologies that are already available. Who knows, perhaps someone out there is actually using their Apple Watch to make changes to a report they need to give in a few hours.

Of course, some developers are in denial. They point out the reams of code already in existence and how organizations around the world will refuse the give them up. The organization may very well refuse to give the desktop application code up, but the user has already done so. Applications require willing users. In the absence of willing users, no mandate will force anyone to use a broken application. Users will find a way around the mandate and it’s likely that no amount of coercion will force users to comply with the dreams of developers who have stuck by the desktop system.

We’re talking average users here. Any user who uses applications for mundane tasks that long ago became the essence of modern business. Developers will still find people who actually do need the power of desktop applications. it’s entirely possible that both engineers and scientists will continue to use desktop applications far into the future, but these applications are at the periphery. The days of the desktop are gone—it’s time to get used to the idea that your next application will probably be web-based and that you’ll use a language appropriate for that venue to create it. In the meantime, you do have options for moving your existing code. Let me know your thoughts about applications that run anywhere on any device at John@JohnMuellerBooks.com.

However, today I find myself having to take a new direction and actually tell people not to use the title attribute because it could potentially make pages less accessible. Part of the reason that the title attribute isn’t used anymore is that some people became confused about it and started using it for Search Engine Optimization (SEO) uses and that was never the point. A lack of browser support and all sorts of other issues added to the demise of the title attribute as a useful link feature. The point is that there is a reason for the title attribute, but no one was using it and people with special accessibility needs found ways around it. At one point, the screen readers I used actually did make use of the title attribute, but newer screen readers don’t. In fact, the new approach is to ensure that links contain enough text to ensure someone with a screen reader knows what they mean. It’s a situation where a specific programming technique didn’t get the job done so another technique is now in use—one that seems more natural and that people are actually using.

So, what cued me into the fact that the title attribute is no longer particularly useful? Well, I use WordPress to create blog posts and noted recently that they had removed the title attribute from the dialog box for creating links. For a while I was adding the title attribute in by hand because I really did feel I was making the page more accessible. However, after talking with a friend about the issue and experimenting with the latest screen readers myself, I find that the title attribute is one of those “also ran” features that simply doesn’t see use often enough to make it worthwhile using. The new strategy is to ensure you provide enough text as part of your link to ensure the link is clear all by itself (even if you need to hide part of that text from view). If you have a copy of one of my books that espouses the use of the title attribute, make sure you change your practice to match what the rest of the world is doing today. Let me know if you have any questions about the use of the title attribute at John@JohnMuellerBooks.com.

There has been a lot of hubbub about net neutrality. I even saw not one, but two articles about the topic in my local newspaper the other day. Of course the discussion has been going on for a while now and will continue to go on—eventually ending up in the courts. My initial interest in the topic is different from almost every other account you read. While everyone else seems to be concerned about how fast their app will run, I’m more concerned about getting new applications out and allowing them to run correctly on a wide range of systems.

Both HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies speak to the need of performance testing. Neither book covers the topic in detail or uses exotic techniques, but it’s an issue every good programming book should cover. Of course, I had no idea at the time I wrote these books that something like net neutrality would become fact. The developer now has something new to worry about. Given that no one else is talking much about developer needs, I decided to write Considering Net Neutrality and API Access. The article considers just how developers are affected by net neutrality.

If net neutrality remains the law of the land, developers of all types will eventually have to rethink strategies for accessing data online as a minimum. However, the effects will manifest themselves in even more ways. For example, consider how net neutrality could affect specialty groups such as data scientists. It will also affect people in situations they never expected. For example, what happens when net neutrality assures equal access speeds for the x-ray needed to save your life and that online game the kid is playing next to you? Will people die in order to assure precisely equal access. So far, I haven’t found anyone talking about these issues. There just seems to be this nebulous idea of what net neutrality might mean.

My thought is that we need a clearer definition of precisely what the FCC means by equal access. It’s also important to define exceptions to the rule, such as medical needs or real time applications, such as self-driving cars. The rules need to spell out what fair really means. As things sit right now, I have to wonder whether net neutrality will end up being another potentially good idea gone really bad because of a lack of planning and foresight. What are your ideas about net neutrality? Let me know at John@JohnMuellerBooks.com.

A lot of people ask me how to use my books to learn a coding technique quickly. I recently wrote two articles for New Relic that help explain the techniques for choosing a technical book and the best way to get precisely the book you want. These articles are important to you, the reader, because I want to be sure that you’ll always like the books you purchase, no matter who wrote them. More importantly, these articles help you get a good start with my coding books because you start with a book that contains something you really do need.

Of course, there is more to the process than simply getting the right book. When you already have some experience with the language and techniques for using it, you can simply look up the appropriate example in the book and use it as a learning aid. However, the vast majority of the people asking this question have absolutely no experience with the language or the techniques for using it. Some people have never written an application or worked with code at all. In this case, there really aren’t any shortcuts. Learning something really does mean spending the time to take the small steps required to obtain the skills required. Someday, there may be a technology that will simply pour the knowledge into your head, but that technology doesn’t exist today.

Even reading a book cover-to-cover won’t help you succeed. My own personal experiences tell me that I need to use multiple strategies to ensure I actually understand a new programming technique and I’ve been doing this for a long time (well over 30 years). Just reading my books won’t make you a coder, you must work harder than that. Here is a quick overview of some techniques that I use when I need to discover a new way of working with code or to learn an entirely new technology (the articles will provide you with more detail):

Modify the examples to obtain different effects or to expand them in specific ways.

Use the coding technique in an existing application.

Talk to other developers about the coding technique.

Research different versions of the coding technique online.

View a video of someone using the technique to perform specific tasks.

There are other methods you can use to work with my books, but this list represents the most common techniques I use. Yes, it’s a relatively long list and they all require some amount of effort on my part to perform. It isn’t possible to learn a new technique without putting in the time required to learn it. In a day of instant gratification, knowledge still requires time to obtain. The wisdom to use the knowledge appropriately, takes even longer. I truly wish there were an easier way to help you get the knowledge needed, but there simply isn’t.

Of course, I’m always here to help you with my books. When you have a book-specific question, I want to hear about it because I want you to have the best possible experience using my books. In addition, unless you tell me that something isn’t working for you, I’ll never know and I won’t be able to discuss solutions for the issue as part of blog post or e-mail resolution.

What methods do you use to make the knowledge you obtain from books work better? The question of how people learn takes up a considerable part of my time, so this is an important question for my future books and making them better. Let me know your thoughts about the question at John@JohnMuellerBooks.com. The same e-mail address also works for your book-specific questions.

Choosing a library for your Web application can be difficult. Both HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies emphasize the need to choose libraries with care. There are all sorts of considerations, such as whether the library enjoys popular support and has a good upgrade policy. You also need to know whether the library is secure and performs all the tasks you require of it in the manner you want them performed. These books do a great job of helping you understand the requirements for choosing a library.

At the time I wrote these books, jQuery was the most popular library available. In fact, both books emphasize use of jQuery for programming needs. It turns out that jQuery is still the most popular library around and for good reason, the producers of jQuery have done just about everything right, so developers continue to support them. If you need general interface and low level programming support, jQuery and jQuery UI are good places to start. What it really comes down to is reducing costs and getting work done faster. Money drives everything on the Internet, including your next project.

Two libraries simply can’t meet every need. Developers often use a wide variety of libraries to get the job done. Choosing the right library can be difficult. There are literally hundreds of them, all purporting to do the job faster, better, and for less money (when money is directly involved in the equation). Choosing the wrong library can incur huge penalties. That’s why a site such as Libscore is so important. You can use Libscore to find the top:

JavaScript Library

Script

Site Using JavaScript

The last option is the most important because it tells you what the top sites are and which libraries they use to achieve their goals. By viewing the site and seeing how it uses a library, you can make intelligent decisions for your own site. Exploring Libscore doesn’t take long, but can net you huge gains in productivity that translate into reduced costs and fewer errors.

I receive more than a few e-mails each week about JavaScript, HTML5, and CSS3. Readers really do want to know my opinion about this library or that. Unfortunately, my ability to test every library out there is limited. In fact, let’s be practical—even if I were to attempt to perform the task full time, I still wouldn’t have time as an individual to test all the options. So, using a site such as Libscore is the best option that I can offer you. I’d love to hear your opinions about Libscore or any other site offering the same functionality at John@JohnMuellerBooks.com. If you send me information about another library scoring site, please make sure it actually works with JavaScript or another viable Web technology.

As our world becomes ever more interconnected, developers rely more and more on code and data sources outside of the environment in which the application runs. Using external code and data sources has a considerable number of advantages, not the least of which is keeping application development on schedule and within budget. However, working with APIs, whether local or on someone else’s system, means performing additional levels of testing. It isn’t enough to know that the application works as planned when used in the way you originally envisioned it being used. That’s why I wrote API Security Testing: Think Like a Bad Guy. This article helps you understand the sorts of attacks you might encounter when working with a third party API or allowing others to use your API.

Knowing the sources and types of potential threats can help you create better debugging processes for your organization. In reality, most security breaches today point to a lack of proper testing and an inability to debug applications because the inner workings of that application are poorly understood by those who maintain them. Blaming the user for interacting with an application incorrectly, hackers for exploiting API weaknesses, or third parties for improperly testing their APIs are simply excuses. Unfortunately, no one is interested in hearing excuses when an application opens a door to user data of various types.

It was serendipity that I was asked to review the recent Snapchat debacle and write an article about it. My editorial appears as Security Lessons Courtesy of Snapchat. The problems with Snapchat are significant and they could have been avoided with proper testing procedures, QA, and debugging techniques.This vendor is doing precisely all the wrong things—I truly couldn’t have asked for a better example to illustrate the issues that can occur when APIs aren’t tested correctly and fully. The results of the security breach are truly devastating from a certain perspective. As far as I know, no one had their identity stolen, but many people have lost their dignity and privacy as a result of the security breach. Certainly, someone will try to extort money from those who have been compromised. After all, you really don’t want your significant other, your boss, or your associates to see that inappropriate picture.

The need to test APIs carefully, fully, and without preconceived notions of how the user will interact with the API is essential. Until APIs become more secure and developers begin to take security seriously, you can expect a continuous stream of security breaches to appear in both the trade press and national media. The disturbing trend is that vendors now tend to blame users, but this really is a dead end. The best advice I can provide to software developers is to assume the user will always attempt to use your application incorrectly, no matter how much training the user receives.

Of course, it isn’t just APIs that require vigorous testing, but applications as a whole. However, errors in APIs tend to be worse because a single API can see use in a number of applications. So, a single error in the API is spread far wider than a similar error in an application. Let me know your thoughts on API security testing at John@JohnMuellerBooks.com.