Answer to a Beginner’s JavaScript Question

A friend of a friend is learning how to code in JavaScript (non-technical, first programming language). Here’s the question:

I’m very early on in the lesson, and I simply can’t wrap my brain around it. It’s like math equations and they just look like gibberish to me. I keep thinking that if I just keep plugging away at it, it will start to make sense, but I’m just stumbling through with no understanding of what I’m doing.

This is simple, basic, beginner code:


And while I kind of get the gist of it, I can’t “read” it like a sentence, where I understand each step, like I do basic HTML and CSS. Stuff like this:

 and this:

I can read it like a sentence and understand each and every word. I’m doubting myself, that if I’m struggling this much with these simple beginner concepts, there is no way in god’s green earth that I will be able to keep up with a bootcamp course. Did y’all have this kind of experience when you were learning? Did you hit a wall, then have a breakthrough and the rest was understandable? Or was this all super easy to you from the start?


The stuff you can read (HTML and CSS) is written in a “declarative programming paradigm.” So congratulations, you understand this style of programming. The other important style you will have to master is the “imperative programming paradigm,” where behavior and flow are implemented in distinct steps. This is the most common and more general-purpose programming paradigm. Most programmers will need to know a mixture of both.

For most beginners, the biggest learning curve is learning your first imperative programming language. Although the concepts will get more and more advanced as you learn, the simplest concepts are often the hardest because you are starting from scratch. The best way to learn is by combination of hands-on (doing), experimenting (tinkering), focused research (asking questions/reading forums), and traditional learning (reading, tutorials, sometimes classroom).

To avoid information overload I recommend that you break things down into small nuggets. You don’t have to understand everything at once. If you are struggling it’s often because you aren’t breaking the problem down into small enough pieces or there is a concept you might be over-complicating. Learning how to code should be fun and rewarding, so if it’s not, you’re doing it wrong. Relax and enjoy the process of experimenting with code. Software developers can get away with reckless experimentation that would otherwise be materially expensive in the real world, so don’t be afraid to make mistakes or get confused in the beginning. Learning can be messy, but it should always be fun. After all, it’s all in your head.

Let’s go over your code snippet. I’ve typed it into notepad, added some minimal HTML, and saved it as a web page on my desktop called “example.html.” I’ve opened it up in Chrome, hit F12 (F12/Debug mode is your friend), and displayed the Console output:



…as you can see from the console output, the gist of the lesson was to demonstrate that the variable “my_number” outside of the function is a *different* variable than “my_number” inside the function. The first is global scope, while the second is function scope (exists only in the function).

To get a better understand of what is going on, here’s an informal explanation of what is happening, line-by-line:

1. var my_number = 7
Assign the number 7 to the GLOBAL scope variable “my_number”

2. var timesTwo = function(number) {
Declare a function called “timesTwo” that takes in a parameter (input variable) “number” We are not running or executing the function here, we are just defining (declaring) it. Later on when we get to the line that says “timesTwo(7)” we are calling it and passing 7 as the value for input variable “number”… but right now we are just declaring the function name and input parameters.

3. var my_number = number * 2;
We are still in the definition of the function “timesTwo.” Here we multiply the input variable “number” by 2 and assign it to the LOCAL scope variable “my_number”. It is unrelated to the GLOBAL scope variable “my_number” on line 1.

4. console.log(“Inside the function my_number is: “);
We are still in the definition of the function “timesTwo.” All we are doing here is displaying the literal string “Inside the function my_number is: ” to the console. I say “literal” because it is in quotes.

Note that in a web browser, the end user won’t be able to see the console. You have to go into debug mode to see console output. It’s just for troubleshooting. In real-world (“production”) code you wouldn’t be doing this, so this is just for simplicity (learning).

5. console.log(my_number);
We are still in the definition of the function “timesTwo.” Here we are displaying the value of the LOCAL variable “my_number,” which will be the local variable “number” times 2. Recall that “number” is an input variable, so we don’t know what will be displayed later until we call our function (“timesTwo”) later on.

6. };
This is the END the definition of the function “timesTwo.” (closing curly brace + end of statement semicolon).

7. timesTwo(7);
Now we are calling (running) the function we have just defined. We are passed in the value 7 for the input parameter (input variable) “number.” Since we are really running through the function now (not just defining it), go through steps 2 through 7 again with the number 7 plugged into “my_number” to see what happens.

NOTE: if you are the kind of person who tends to overthink things, you may be confused as to why the literal number 7 was passed in instead the value of GLOBAL scope my_number, which was also 7. I’m not sure why other than perhaps the author of this example wanted to show that 7 could be passed in literally (directly) rather than using the variable. Sometimes when you read code you must keep your inferences and judgments separate from your observations–that’s a troubleshooting skill that you will develop over the years (balance of critical thinking, scientific method, observation, inference, and intuition).

8. console.log(“Outside the function my_number is: “);
All we are doing here is displaying the literal string “Outside the function my_number is: ” to the console.

9. console.log(my_number);
Here we display the GLOBAL scope variable my_number. Notice that is hasn’t changed since line 1. You could pretty much delete lines 2 through 8 and you would get the same answer on line 9.

Although the language is JavaScript, I’ve seen this lesson since the 1980’s across several different languages: BASIC, FORTRAN, Pascal, C, C++, Visual Basic, C#, and Java. There will be some gotchas with JavaScript variable scope compared to those other languages, but in the general case (and certainly this case), the variable scope rules are the same.

Hope this helps.

How to Choose the Right Service Bus

How to Choose the Right Enterprise Service Bus

Gartner Magic Quadrant: ESB vendors 2012

After reading the above two sources, you might begin to think that the Oracle and IBM SOA solutions are overkill, too expensive, or requires too much vendor lock-in for your needs. If so, read on:

Apache Camel (Integration Framework) VS
Apache ServiceMix (OSGI Container) VS
Mule ESB

NServiceBus + ServiceMatrix/ServiceInsight/ServicePulse

Low Cost SOA using Microsoft technologies
If you are a Microsoft-stack developer, then this paper is really easy to follow. If your SOA needs are simple then some of the solutions he mentions may be enough for your project. Although the paper covers the VETO service mediation pattern, you should also look up VETRO–the R (“Routing”) is important.


IISExpress in Application Server Mode: External + HTTPS

IIS Express can also be run from the command line in “Application Server Mode”. (REF: This option is desirable if you need to run IIS outside of Visual Studio; however, due to a design limitation (flaw?) in the iisexpress.exe command-line, you can’t use the HTTPS protocol, only HTTP. I’ve found a reasonable workaround in PowerShell that works with both IIS 7.5 and 8. We take advantage of the \config option to load in our own customizations. We override the protocol to allow HTTPS and also broaden the port bindings (we want the site to be accessible by other systems for testing, not just localhost, so we drop “localhost” from the port’s bindingInformation).

NOTE: You may first need to make a one-time reservation of the port using “netsh http add urlacl url=… user=…” from an elevated command prompt. “netstat -ab” can help determine which ports are in use. (The “b” option requires an elevated command prompt but it gives you the process names.)

If you get this exception when you run the above script:
Failed to register URL “http://*:8080/” for site “Development Web Site” application “/”. Error description: Access is denied. (0x80070005)

Then you’ve need to make the one-time reservation of the port I mentioned earlier. Set this from an elevated command prompt:
netsh http add urlacl url=http://*:8080/ user=everyone

Of course, substitute whatever port you are trying to set for 8080; for example, 44300 for HTTPS:
netsh http add urlacl url=https://*:44300/ user=everyone

SalesForce Canvas Library for .Net does not directly support CORS or JSONP for cross-origin resource sharing of an IFRAME; instead, they have their own implementation called SalesForce Canvas. Since SalesForce instances (and therefore your IFRAMEd application) must be exposed to the Internet, some validation is required. It involves reading an encoded “signed request” and comparing a hash of it against a SalesForce consumer secret known by the non-SalesForce application. If those two things match up, we can assume the request is valid and use the OAuth token and other rich user+server contextual information provided by SalesForce. This contextual information is required for eventing over XmlHttpRequest (XHR). For security reasons the validation of the signed request against the consumer secret should be done server-side.

SalesForce has a nice PDF about Canvas at It even covers publish-subscribe XHR eventing between the application and SalesForce; however, the thing I don’t like about their documentation is that they push their Heroku platform too much in their examples. Although it’s cool if you are looking for a PaaS, if not, Heroku is unnecessary and complicates things when you are just trying to grasp the basics. If you’re a .Net developer you have to substitute your own equivalents as you go through their tutorial, so I wrote a simple library in C# with two simple “Hello-World”-style examples, one in ASP.Net MVC and the other in ASP.Net Web Forms. Here’s a link to my implementation in GitHub:

It includes a tutorial ( for configuring your SalesForce Connected App to work with this example.

Unit Testing 101

Practical Definition of a Unit Test

The number of units in a “Unit Test” is typically one isolated software module. If there are two or more dependent software modules being tested, it is an integration test. Since a “software module” is often a class, a unit test class usually tests one class, and a unit test method usually tests one method.  A true unit test does not contain volatile dependencies such as  file I/O, networks, databases, web services, web servers, message queuing, randomness, or specific date/times.

From <> :

The whole point of UnitTests is to reduce the scope of the system under test to a small subset that can be tested in isolation. Thus, by the ScientificMethod, we reduce the number of variables that may affect the results so we can derive useful information on whether the unit is actually correct.” — SunirShah

 Hardly by anything as rigid as ScientificMethod, I’d say. Simple good judgment, informed by experience, is more like what most testers and programmers use. — RonJeffries

Also see for Roy Osherove’s definition of a good unit test.

Mocking Your Volatile Dependencies

One practical way to determine if a test contains volatile dependencies is to ask yourself, “Will this test run quickly and dependably on a bare-bones build server*?” If it cannot, then it’s because of a volatile dependency.

* The “build server” in question would be a minimalist install with just the .Net framework, possibly Visual Studio (although most of that wouldn’t be needed) and the required testing, mocking, and build libraries, but not any other runtimes, and certainly NOT IIS or SQL Server, at least not for builds.

Use Dependency Injection techniques to replace volatile dependencies with Test Doubles. Since most classes contain instances of other classes, you must design your classes so that volatile dependencies can be substituted for unit testing. If you don’t design your classes to use dependency injection you may only be able to write integration tests for them:

  • Your unit tests will be limited to only very simple classes or have superficial coverage–they will often be of low value.
  • While your integration tests may still be useful, you may find some of them to be brittle or impractical to automate and/or maintain.

If you have worked with Inversion of Control (IoC) techniques and/or DI Containers you’ll already be familiar with Dependency Injection. Understanding IoC and DI techniques are prerequisites to understanding design patterns and unit testing.


Don’t Reinvent the Wheel

When implementing Test Doubles, prefer a mocking framework over do-it-yourself Stubs. If you don’t do this you may end up with just as much or more test code than the code you are testing. A clean, simple, yet powerful mocking framework for .Net is NSubstitute (

NSubstitute is even simpler to use than Moq; Rhino Mocks was once popular but now suffers from having to support too much backwards compatibility; Microsoft Fakes comes with Visual Studio 2012 but it has not yet caught on.


“Good” Unit Tests

According to Roy Osherove’s “The Art of Unit Testing,” automated tests that take too long to run on a build system or require some external setup are probably not unit tests. A good unit should have these qualities:

  • Automated piece of code that invokes a different method and then checks some assumptions on the logical behavior of that method or class.
  • Written using a unit-testing framework.
  • Written easily.
  • Runs quickly.
  • Can be executed repeatedly by anyone on the development team. It should run at the push of a button and/or on a build system.

A system that contains many components that are difficult or impossible to unit test often indicates high coupling with low cohesion. Low quality design is often difficult to test. Following good design practices like S.O.L.I.D principles leads to a more testable system.

One of the first things to watch out for are classes that directly or indirectly involve databases, files, and logging. Unit tests should be able to run in memory. Even if you have integration tests, it’s still a good idea to eliminate  these volatilities from those classes if possible. When persistence is involved it introduces these problems:

  • Time: usually orders of magnitude longer than memory access and subject to physical volatility of the I/O device.
  • Location: behavior may differ from one environment to another.
  • Dependability
    • Also subject to physical volatility of the I/O device.
    • Possibility of transient or intermittent sharing or locking issues.
  • Hidden complexities:
    • Rather than testing just the code logic you may find yourself working around the persistence mechanism itself (especially databases).
    • If a network is involved it becomes yet another volatile factor.

Databases are difficult to test.

  • If you are using a Repository object model (as recommended for MVC), you may be able to mock the repository.
  • Some continuous integration environments allow for automated testing of a database. Although it is not true unit testing and requires a lot of setting up (tear down/recreate for testing), it may be a practical progression once you get a handle on your unit tests.

In .Net, if you need to test a non-public method (and have decided that it’s not a good idea to make the method public just for testing), use the InternalsVisibleTo assembly attribute in the Software Under Test’s [SUT's] AssemblyInfo.cs file.The SUT has to know the name of the assembly that is testing it, so it is technically “backwards coupling” by name; however,

  • it won’t break the SUT if the test assembly in the attribute goes away or if the name is incorrect, and
  • in version 2.0 of the .Net framework the attribute was specifically added by Microsoft developers as a workaround to having to use reflection tricks to test private or internal methods and members.

Integration Tests Have Their Place

Automated integration testing has its place. Just because a test isn’t a good unit test doesn’t mean it’s a bad test–it might be a great automated integration test. You need to know when you are writing an integration test rather than a unit test because calling an integration test a unit test can cause problems when automating the tests. The volatile parts may also change temporarily or permanently, which may cause your tests to either break or become invalid.

You shouldn’t use integration testing as an excuse for not writing unit tests. If you can write good unit tests your integration tests will improve as well. You should design new code to be unit testable, but also use integration tests to cover important scenarios.

See also: