Coding Schools and the Learning Process

There are three essential ways to begin a career as a developer. The first is to get a college degree in the subject, which is normally a Bachelor of Computer Science or a Bachelor of Information Technology (amongst other degrees). The second is to teach yourself the trade, which means spending a lot of time with books and in front of your screen working through online tutorials. The third is a new option, coding school. The third option has become extremely popular due to limitations in the first two techniques.

The cost of a college education has continued to skyrocket over the past few decades until it has started to elude the grasp of more than a few people. I’ve read estimates that a college degree now costs between $20,000 and $100,000 in various places. How much you actually pay depends on the school, your personal needs, and the electives you choose. The point is that many people are looking for something less expensive.

A college education also requires a large investment in time. A four year degree may require five or six years to actually complete because most people have to work while they’re going to school. A degree is only four years when you can go full time and apply yourself fully. Someone who is out of work today and needs a job immediately can’t wait for five or six years to get a job.

Teaching yourself is a time-honored method of obtaining new skills. I’ve personally taught myself a considerable number of skills. However, I’m also not trying to market those skills to someone else. My self-taught skills usually come in the areas of crafting or self-sufficiency (or sometimes a new programming language). The problem with being self-taught is that you have no independent assessment of your skills and most employers can’t take time to test them. An employer needs someone with a proven set of skills. Consequently, self-teaching is extremely useful for learning new hobbies or adding to existing (proven) skills, but almost valueless when getting a new job. In addition, few people are actually motivated enough to learn a new skill completely (at the same level as a college graduate) on their own.

Coding schools overcome the problem with self-teaching because they offer proof of your skills and ensure you get a consistent level of training. You get the required sheepskin to show to employers. They also address deficiencies in the college approach. The time factor is favorable because most of these schools promise to teach you basic development skills in three months (compared to the five or six years required by a college). In addition, the cost is significantly less (between $6,000 and $18,000). So, it would seem that going to a coding school is the optimum choice.

Recently people have begun to question the ability of coding schools to fulfill the promises they make. It’s important to consider what a coding school is offering before you go to one. The schools vary greatly in what they offer (you can see reviews of three popular code schools at http://www.mikelapeter.com/code-school-vs-treehouse-vs-codecademy-a-review/). However, there are similarities between schools. A coding school teaches you the bare basics of a language. You don’t gain the sort of experience that a college graduate would have. In addition, coding schools don’t teach such concepts as application design or how to work in a team environment. You don’t learn the low-level concepts of how application development works. I don’t know if building a compiler is still part of the curriculum at colleges, but it was one of my more important learning experiences because I gained insights into how my code actually ended up turning switches on and off within the chips housed in the computer.

I see coding schools as fulfilling an important role—helping those who do have programming skills to build competence in a new language quickly. In addition, a coding school could provide an entry point for someone who thinks they may want a computer science degree, but isn’t certain. Spending a short time in a coding school is better than spending a year or two in college and only then finding out that computer science isn’t what the person wants. Coding schools could also help people who need to know how to write simple applications as part of another occupation. For example, a researcher could learn the basic skills require to write simple applications to aid in their main occupation.

People learn in different ways. It’s the lesson that readers keep driving home to me. Some people learn with hands on exercises, some by reading, and still others by researching on their own. Coding schools can fulfill an important role in teaching computer science, but they’re not even close to a complete solution. In order to get the full story about computer science, a student must be willing to invest the required time. Until we discover some method for simply pouring information into the minds of people, the time-consuming approach to learning must continue as it has for thousands of year. There really aren’t any shortcuts when it comes to learning. Let me know your thoughts about coding schools at John@JohnMuellerBooks.com.

 

Death of Windows XP? (Part 3)

Questions continue to come in from readers who are still using Windows XP despite the fact that Microsoft is only marginally supporting it. Yes, it’s the operating system that refuses to die and readers really are confused as to why Microsoft has decided to kill what is obviously a popular operating system. They’re in good company. In fact, some authors, such as John Dvorak, have gone a lot further in their negative comments regarding the demise of Windows XP. The point is that Microsoft is quite determined to force anyone they can into using Windows 8.1, whether it works for them or not. It doesn’t seem to matter that people still have perfectly usable systems that are happily running Windows XP without problem.

My first two posts on this topic, Death of Windows XP? and Death of Windows XP? (Part 2) should have addressed any questions that people reading my books might have. Essentially, I recommend updating to Windows 7 (for business users) or Windows 8.1 (for consumers) when your hardware begins to die of old age or your needs change.

 


I no longer have access to a Windows XP system, so I’m not able to provide support for my old Windows XP books at this point in time. If you have one of my old Windows XP books, you’ll need to use it as is. I haven’t purposely gone out of my way to orphan the books, but the technology is old and I simply don’t have the resources to provide support for these books any longer. In addition, none of my current programming books are designed for Windows XP developers.

In the meantime, you need to ensure that you get security updates. Microsoft has extended a limited level of security support until 14 July 2015 that includes malware signatures and the associated engine. You won’t receive any sort of bug fixes. In order to enhance the security of your environment, you may want to consider these changes to your system:


  • Use a browser that receives regular security upgrades, such as Chrome or Firefox (IE is a bad choice because Microsoft won’t update it).

  • Remove any software that is prone to security problems, such as Java.

  • Rely on an account with limited privileges, rather than use the Administrator account.
  • Update any application software as often as is possible.
  • Keep the number of installed applications as small as is possible.
  • Examine your system (especially your hard drive) for signs of intruders (such as unexplained processes) on a regular basis.

  • Stay offline whenever possible.

These strategies can help you out for a while, but they’re short term solutions. Eventually, you need to go offline permanently (such as when using the system to run older games) or upgrade to something newer. Please let me know whether you have any additional questions about Windows XP and how it affects support for my books at John@JohnMuellerBooks.com.

An Update on the RunAs Command

It has been a while since I wrote the Simulating Users with the RunAs Command post that describes how to use the RunAs command to perform tasks that the user’s account can’t normally perform. (The basics of using the RunAs command appear in both Administering Windows Server 2008 Server Core and Windows Command-Line Administration Instant Reference.) A number of you have written to tell me that there is a problem with using the RunAs command with built-in commands—those that appear as part of CMD.EXE. For example, when you try the following command:

RunAs /User:Administrator “md \Temp”

you are asked for the Administrator password as normal. After you supply the password, you get two error messages:

RUNAS ERROR: Unable to run – md \Temp
2: The system cannot find the file specified.

In fact, you find that built-in commands as a whole won’t work as anticipated. One way to overcome this problem is to place the commands in a batch file and then run the batch file as an administrator. This solution works fine when you plan to execute the command regularly. However, it’s not optimal when you plan to execute the command just once or twice. In this case, you must execute a copy of the command processor and use it to execute the command as shown here:

RunAs /User:Administrator “cmd /c \”md \Temp””

This command looks pretty convoluted, but it’s straightforward if you take it apart a little at a time. At the heart of everything is the md \Temp part of the command. In order to make this a separate command, you must enclose it in double quotes. Remember to escape the double quote that appears withing the command string by using a backslash (as in \”).

To execute the command processor, you simply type cmd. However, you want the command processor to start, execute the command, and then terminate, so you also add the /c command line switch. The command processor string is also enclosed within double quotes to make it appear as a single command to RunAs.

 

Make sure you use forward slashes and backslashes as needed. Using the wrong slash will make the command fail.

The RunAs command can now proceed as you normally use it. In this case, the command only includes the username. You can also include the password, when necessary. Let me know if you find this workaround helpful at John@JohnMuellerBooks.com.

 

Death of Windows XP? (Part 2)

The fact that Windows XP, despite some pretty aggressive attack by Microsoft on its own product, is still alive isn’t in doubt. Of course, there is the matter of support to consider. Microsoft has decided not to provide any more support for Windows XP unless you’re a big company or government organization with immensely deep pockets and have a lot of cash to spend. Stories abound about the Dutch and British governments forking over huge bucks to keep their copies of Windows XP patched. Of course, the IRS is in on it too. (Microsoft begrudgingly decided to provide security updates for Windows XP until 14 July 2015 after a lot of complaining.)

My previous post on this topic, Death of Windows XP?, discussed some of the pros and cons of keeping the aging operating system around. In general, it’s a good idea to update to Windows 7 if you have equipment that can run it. Windows 8 has received a lot of negative press, especially for business needs. After working with it for a while myself, I see it as a good consumer operating system, but not necessarily something a business would want to use. Even with the updates, Windows 8 simply forces the user to work too hard to get things done in a manner that businesses would normally do them.

What surprised me this past week (and it shouldn’t have) is that some larger organizations are taking matters into their own hands. For example, if you’re a Windows XP user in China, you can get updates for your Windows XP installation from Qihoo 360. The point is that it appears that Windows XP will continue to receive patches and security updates even if Microsoft isn’t involved. This process almost reminds me of what happened to IBM when it started to drop the ball on the PC. At one time, everything revolved around IBM, but then the company made some really bad decisions and third parties had an opportunity to take control of the market (which they promptly did).

Whether you believe Windows XP is worth saving or not isn’t the issue. What the whole Windows XP scenario points out is that Microsoft is losing it’s grip on the market, even the desktop market where it once reigned supreme. What are your thoughts about Microsoft’s future? Let me know at John@JohnMuellerBooks.com.

 

VBA’s Long Lasting Viability

Microsoft has taken great pains over the years to try to kill VBA off. I’ve discussed some of the issues surrounding this effort in two previous posts: VBA and Office 2013 and VBA and Office 2013 (Part 2). Because of these efforts, a number of people have written to ask me about VBA and my book about it. The fact of the matter is that most of the examples in VBA for Dummies continue to work fine and VBA remains a viable development platform for applications. Microsoft’s efforts to move VBA developers to Visual Studio Tools for Office (VSTO) haven’t been as successful as Microsoft would like—mostly because most VBA developers have other careers and don’t want to learn how to use VSTO.

I do continue to provide updates for my book in the VBA for Dummies category of this blog. The latest such post discusses trigonometric calculations in VBA. As you find book issues, I’ll continue to address them in this blog. In addition, as time permits, I’ll discuss VBA issues in general and provide additional examples that relate to the content in my book. All I really need is your input at John@JohnMuellerBooks.com to know what sorts of content you’d like to see. Your e-mails help me decide which issues are most important to you, so please do write when you see a particular need.

Of course, the biggest question about VBA is the one I haven’t answered yet. Some people have wondered whether VBA is still a viable language for new development. The fact that even Microsoft has provided updated macros for VBA should tell you something. If there were no interest in new development, you can be sure that Microsoft wouldn’t waste time in posting macros for Office 2013. In fact, a Google search shows 122,000 hits for sites that have updated their VBA information in the last year. That’s a lot of interest in a language that Microsoft has tried so hard to kill off.

I still see VBA as the language to use when you have any sort of Office automation need—VSTO is a better choice when you actually want to extend Office functionality or define new behaviors (work that full-fledged developers normally perform). It’s incredibly easy to use and most people can learn to use the basic features quite quickly. In fact, because it’s interpreted, VBA makes a great way for people to start learning basic programming principles.

The only caveat for today is to ensure that your code doesn’t have any compatibility issues, especially if you plan to use your VBA macros with Office 365. There is a lot of old code out there that might not work with newer versions of Office. With this in mind, Microsoft has created the Office Code Compatibility Inspector (OCCI). Make sure you download as use this tool to check your code.

 

Death of Windows XP?

There have been a lot of stories in the trade press about Windows XP as of late. A number of readers have written to ask about the aging operating system because they’re confused by stories from one side that say everyone is sticking with Windows XP and stories from the other that say people are abandoning it. Windows XP is certainly one of the longest lasting and favored operating systems that Microsoft has produced, so it’s not surprising there is so much confusion about it.

Microsoft is certainly putting a lot of effort into getting rid of the aging operating system and for good reason—the code has become hard to maintain. Development decisions that seemed appropriate at the time Windows XP was created have proven not to work out in the long run. Of course, there are monetary reasons for getting rid of Windows XP as well. A company can’t continue to operate if no one buys new product. It must receive a constant influx of funds to stay in business, even a company as large as Microsoft. In short, if you’re Microsoft and you want to stay in business, rather than service what has become an unreliable operating system, you do anything it takes to move people in some other direction.

On the other side of the fence are people are are simply happy with the operating system they have today. The equipment they own is paid for and there isn’t a strong business reason to move to some other platform until said equipment breaks. The reliability of computer equipment is such today that it can last quite a long time without replacement. Theoretically, based on reliability alone, it’s possible that people will continue to use Windows XP for many more years. I have such as system setup to hold my movie database and to play older games I enjoy, but I don’t network it with any other equipment and it definitely doesn’t have access to the Internet.

From many perspectives, reports of the death of Windows XP are likely premature. The latest statistics still place the Windows XP market share above 27 percent. Even when Microsoft’s support goes away on April 8th, many third party vendors will continue to support Windows XP. What Microsoft’s end of support means is that you won’t get any new drivers for new hardware or upgrades to core operating system features. However, you can still get updates to your virus protection and Windows XP will continue to operate with your existing hardware.

For most people, the question of whether to keep Windows XP around hinges around the simple question of whether the operating system still fulfills every need. If this is the case, there really isn’t any reason to succumb to the fear mongering that is taking place and move to something else. However, once your equipment does start to break down or you find that Windows XP doesn’t quite fit the bill any longer, try moving along to something newer.

As to the essential question about the level of Windows XP support I’m willing to provide for my books, it depends on the book. My system no longer has development software on it because developers have moved on to other platforms. So, if you ask me programming questions about Windows XP, I’m not going to be able to help you. To some extent, I can offer a little help with user-level support questions for a few of my older books. However, I won’t be able to cover issues that my support system doesn’t address any longer, such as connecting to a network or the Internet. In sum, even though I can offer you some level of support in many cases, I can’t continue to provide the full support I once did. Let me know about your Windows XP book support questions at John@JohnMuellerBooks.com.

 

In Praise of Dual Monitors

A lot of people have claimed that the desktop system is dead—that people are only interested in using tablets and smartphones for computing. In fact, there is concern that the desktop might become a thing of the past. It’s true that my own efforts, such as HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies, have started to focus on mobile development. However, I plan to continue using my desktop system when working because it’s a lot more practical and saves me considerable time. One such time saver is the use of dual monitors.

Yes, I know that some developers use more than just two monitors, but I find that two monitors work just fine. The first monitor is my work monitor—the monitor I use for actually typing code. The second monitor is my view monitor. When I run the application, the output appears on the second monitor so that I can see the result of changes I’ve made. Using two monitors lets me easily correlate the change in code to the changes in application design. Otherwise, I’d be wasting time switching between the application output and my IDE.

I also use two monitors when writing my books. The work monitor contains my word processor, while my view monitor contains the application I’m writing about. This is possibly one time when a third monitor could be helpful—one to hold the word processor, one to hold the IDE, and one to view the application output. However, in this case, a third monitor could actually slow things down because the time spent viewing the output of an example is small when compared to creating a production application.

The concept of separating work from the source of information used to perform the work isn’t new. People have used the idea for thousands of years, in fact. For example, when people employed typewriters to output printed text, the typist employed a special stand to hold the manuscript being typed. The idea of having a view of your work and then another surface to actually work on is used quite often throughout history because it’s a convenient way to perform tasks quickly. By employing dual monitors, I commonly get between a 15 percent to 33 percent increase in output, simply because I can see my work and its associated view at the same time.

Working with dual monitors not only saves time, but can also reduce errors. By typing as I view the output of applications, I can more reliably relate the text of labels and other information the application provides. The same holds true when viewing information sources found in other locations. Seeing the information as I type it is always less likely to produce errors.

Don’t get the idea that I support using dual monitors in every situation. Many consumer-oriented computer uses are served just fine with a single monitor. For example, there isn’t a good reason to use two monitors when viewing e-mail in many cases—at least, not at the consumer level (you could make a case for using dual monitors when working with e-mails and a calendar to manage tasks, for example). Dual monitors commonly see use in the business environment because people aren’t necessarily creating their own information source—the information comes from a variety of sources that the user must view in order to use reliably.

Do you see yourself using dual monitors? If you use such a setup now, how do you employ it? Let me know at John@JohnMuellerBooks.com.

 

Choosing Variable Names

It often surprises me that developers seem to choose completely useless variable names like MyVariable when creating an application. Although MyVariable could be an interesting variable name for an example in a book, it never has a place in any sort of production code. Even then, I try to create book examples with meaningful variable names, especially when getting past the initial “Hello World” example. Variable names are important because they tell others:

 

  • What sort of information the variable stores
  • When the variable is commonly used
  • Where the variable is used
  • How to use the variable correctly
  • Why the variable is important


In some cases, the variable name could even indicate who created the variable; although, this sort of information is extremely rare. If you never thought a variable name should contain all that information, then perhaps you haven’t been choosing the best variable names for your application.

Even with these restrictions in place, choosing a variable name can be uncommonly hard if you want to maximize the name’s value to both yourself and other developers. Some organizations make the selection process easier by following certain conventions. For example, a form of Hungarian Notation, where certain type prefixes, suffixes, and other naming conventions are used, is a common way to reduce the complexity of creating a variable name. In fact, Hungarian Notation (or some form of it) is often used to name objects, methods, functions, classes, and other programming elements as well. For example, NamArCustomers could be an array of customer names (Nam for names, Ar for array). The use of these two prefixes would make it instantly apparent when the variable is being used incorrectly, such as assigning a list of numbers to the array. The point is that an organizational variable naming policy can reduce complexity, make the names easy to read for anyone, and reduces the time the developer spends choosing a name.

 

Before I get a ton of e-mail on the topic, yes, I know that many people view Hungarian notation as the worst possible way to name variables. They point out that it only really works with statically typed languages and that it doesn’t work at all for languages such as JavaScript. All that I’m really pointing out is that some sort of naming convention is helpful—whether you use something specific like Hungarian Notation is up to you.


Any variable name you create should convey the meaning of that variable to anyone. If you aren’t using some sort of pattern or policy to name the variables, then create a convention that helps you create the names in a consistent manner and document it. When you create a variable name, you need to consider these kinds of questions:

 

  1. What information does the variable contain (such as a list of names)?
  2. How is the variable used (such as locally or globally, or to contain coordinates, or a special kind of object)?
  3. When appropriate, what kind of information does the variable contain (such as a string or the coordinate of a pixel on screen)?
  4. Is the variable used for a special task (such as data conversion)?
  5. What case should prefixes, suffixes, and other naming elements appear in when a language is case sensitive?

The point is that you need to choose variable names with care so that you know what they mean later. Carefully chosen variable names make it possible for you to read your code with greater ease and locate bugs a lot faster. They also make it easier for others to understand your code and for you to remember what the code does months after you’ve written it. However, most important of all, useful variable names help you see immediately that a variable is being using the wrong way, such as assigning the length of a name string to a coordinate position on screen (even though both variables are integer values). Let me know your thoughts about variable naming at John@JohnMuellerBooks.com.

 

Keeping Your CSS Clean

It happens to everyone. Even with the best intentions, your code can become messy and unmanageable. When that code is compiled into an executable, the compiler can perform some level of cleanup and optimization for you. However, when you’re working with a text-based technology, such as Cascading Style Sheets (CSS), the accumulated grime ends up slowing your application measurably, which serves to frustrate users. Frustrated users click the next link in line, rather than deal with an application that doesn’t work as they think it should. It doesn’t take long to figure out that you really must keep your CSS clean if you plan to keep your users happy (and using your application).

Manually cleaning your code is a possibility, as is keeping your code clean in the first place. Both solutions can work when you’re a lone developer or possibly working as part of a small team. The problem begins when you’re part of a larger team and there are any number of people working on the code at the same time. As the size of the team increases, so does the potential for gunky code that affects application speed, reliability, and security negatively. In order to clean code in a team environment, you really do need some level of automation, which is why I wrote Five Free Tools to Clean Up Your CSS. This article provides good advice on which tools will help you get the most out of your application.

The cleaner you keep your code, the faster the application will run and the less likely it is to have reliability and security problems. Of course, there are many other quality issues you must consider as part of browser-based application development. Messy CSS does cause woe for a lot of developers, but it isn’t the only source of problems. I’ll cover some of these other issues in future posts. What I’d like to hear now is what you consider the worst offenders when it comes to application speed, reliability, and security problems. Let me know about your main source of worry at John@JohnMuellerBooks.com.

 

JavaScript Updates in the Offing

Readers of both HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies need to know about updates in JavaScript because both books rely on JavaScript to demonstrate programming concepts. The current version of JavaScript works exceptionally well for Web-based applications. You see such applications all the time. In fact, many people now use more Web-based applications than desktop applications to perform their work. For example, I’m using a Web-based application to create this post. I also envision a day when I won’t use Word to write my books any longer and will instead rely on a Web-based application to perform the task. However, the current version of JavaScript could use some improvements to make it easier to use and more bulletproof as well.

There are currently discussions for both JavaScript 6 and 7. (In fact, you can find some early discussions for JavaScript 8 as well.) The discussions are taking place in parallel to ensure that JavaScript 6 coordinates well with JavaScript 7 and to allow one version to naturally flow into the next. JavaScript 6 should appear by the end of next year (2014). Given the complexity of language upgrades, however, it wouldn’t surprise me if there were a delay or two. It’s important to get the changes right and obtaining consensus on the changes is going to be difficult because of the complexity of the changes.

With this in mind, I’ll probably ignore JavaScript 7 for right now and focus my attention on the JavaScript 6 changes. Obviously, if someone wants to talk about JavaScript 7 (or even version 8), I’m all ears. I always want to hear your viewpoint on looming upgrades. However, the focus for me now is on using JavaScript 6 to make the coding examples in my books better.

The big news for JavaScript 6 as far as I’m concerned is the implementation of modules. Using modules will make it a lot easier for developers to share code. The specification contains a good deal more than modules, but the feature most developers are focusing on is the use of modules for sharing code in ways that the current use of APIs and other code sharing techniques won’t address. In fact, the essential goals for modules are:

 


  • Get rid of the need for global variables
  • Make it possible to refactor global code as modular code
  • Reduce the effort required to use JavaScript module systems
  • Speed compilation
  • Simplify JavaScript applications
  • Improve JavaScript usability
  • Define a standard protocol for creating and using libraries
  • Make browser and non-browser environments more compatible
  • Reduce the work required to load external modules asynchronously


Some of these goals are pretty hard to understand right now and a few of them are only in the discussion stage. However, some browser vendors, such as Mozilla, are already discussing how JavaScript will work in their applications. It won’t be long and you’ll want to start thinking about the functionality that JavaScript 6 could add to your applications, even if you don’t implement this functionality immediately.

I’m convinced that the future of development lies with environments that allow you to create one application that runs everywhere. No, desktop applications won’t go away for quite some time (or possibly ever), but if you want to be involved in the technology that will dictate future application requirements, then you need to start considering releases such as JavaScript 6. Let me know your thoughts on this upgrade. I’d also love to hear your questions about it at John@JohnMuellerBooks.com. I’ll use any really good ideas/questions for future blog posts.