بيا تا گل برافشانيم و مي در ساغر اندازيم
فلک را سقف بشکافيم و طرحي نو دراندازيم

اگر غم لشکر انگيزد که خون عاشقان ريزد
من و ساقي به هم تازيم و بنيادش براندازيم

شراب ارغواني را گلاب اندر قدح ريزيم
نسيم عطرگردان را شکر در مجمر اندازيم

چو در دست است رودي خوش بزن مطرب سرودي خوش
که دست افشان غزل خوانيم و پاکوبان سر اندازيم

صبا خاک وجود ما بدان عالي جناب انداز
بود کآن شاه خوبان را نظر بر منظر اندازيم

يکي از عقل مي لافد يکي طامات مي بافد
بيا کاين داوري ها را به پيش داور اندازيم

بهشت عدن اگر خواهي بيا با ما به ميخانه
که از پاي خمت روزي به حوض کوثر اندازيم

سخنداني و خوشخواني نمي ورزند در شيراز
بيا حافظ که تا خود را به ملکي ديگر اندازيم

Nobody actually makes single page apps in a single page anymore, do they? Some are saying they should really be called native web apps, which sounds fine to me. Anyway, coincidentally two readers sent me their own single page app libraries. They both build applications from separate files, but work in quite different ways.

Griffin.yo (jgauffin/griffin.yo, License: Apache 2.0) by Jonas Gauffin is a framework written in TypeScript that supports templates, view models, routing, and caching of server-side data.

Once views and models have been loaded they are cached in the browser (the cache is emptied if the browser is reloaded). Thus as long as the user continues to use the site as a SPA application everything is only loaded once from the server.

There's a blog post about Griffin.yo that introduces the main ideas, and the examples are written with TypeScript. It uses a project structure that is similar to many other web frameworks. I don't think there's a project generator, so follow the quick start guide if you want to try it out.

The other SPA project I was sent recently is Igaro App (GitHub: igaro/app, License: GPL). The author, Andrew Charnley, claims it's faster than AngularJS, and the current version is 1.0.0.

The thing that makes Igaro different is it's HTML-free. It avoids using DOM query selector methods to try to improve performance, and therefore has no template engine. Instead it uses routes to build pages, and standard CSS for styling and layout.

There's a DOM element creation API, so you can make elements in a way that reminds me of React:

model.managers.dom.mk('p', wrapper,_tr('Localized string'), 'myClassName');  

Objects created by Igaro are decorated with features for two-way parent-child event management, and dependency tracking. You can do this to arbitrary objects by using the bless method. Bless could be used to make widgets that work with Igaro apps.

In terms of ES6 support, Igaro makes heavy use of promises, which makes sense. Given the use of string fragments over templates, I expected to see ES6 template strings. I couldn't find any examples of template strings in Igaro, but given that it has a Grunt-based build system I don't think it would be too hard to add Babel to an Igaro project.

You can see examples in the documentation: all of the documentation pages are written with Igaro, and if you click the curly braces at the top of the page you'll see the raw JavaScript that's used to generate the page.

I think the paradigm shift to "native web apps" is the right way forward for single page web apps. Rather than the community settling into Angular or React it seems like we're making more libraries – and more creative libraries – than ever!

ECMAScript 6 has been finalised under Standard ECMA-262 6th edition (June 2015). There's no going back now! The JavaScript community can breathe a sigh of relief before gearing up for the next major language revision. Or will we all live in the future using transpilers? Let's take a minute to look at ECMAScript 2015's language features.

Declarations

JavaScript's scoping rules are difficult to understand because var behaves inconsistently depending on scope. The new keywords, let (MDN) and const (MDN), scope based on lexical environment:

Usually a Lexical Environment is associated with some specific syntactic structure of ECMAScript code such as a FunctionDeclaration, a BlockStatement, or a Catch clause of a TryStatement and a new Lexical Environment is created each time such code is evaluated.

So, not only do you get the extra expressive power of being able to declare constants, but you also get the ability to declare variables according to more natural scoping rules. Basically: let works the way most of us thought var did at some point when we learned JavaScript.

Here's something you can try in a Chrome debugger to see how this works:

(function() {
  'use strict'
  for (let i = 0; i < 3; i++) {
    console.log('loop:', i);
  }
  console.log('after loop:', typeof i);
})();

The last statement will show that i is undefined after the loop. Now try this:

(function() {
  'use strict'
  for (var i = 0; i < 3; i++) {
    console.log('loop:', i);
  }
  console.log('after loop:', typeof i);
})();

You should see that i still exists after the loop. Almost everyone I've ever explained this to has forgotten it within a week. The new wisdom is this: you probably want const! If not let. Let's forget about var and everything will be OK.

Arrow Functions

If you think it's weird that for doesn't exist in the same dimension as var, then what about this in anonymous methods? It's very easy to make the mistake of passing a function to a method and assuming this will be bound to the object that owns the method. What really happens is this becomes the global object.

Arrow functions (MDN) help avoid unbound weirdo global this and also makes anonymous functions more readable:

setTimeout(() => { console.log('Hello'); }, 1000);  

Arrow functions may omit the curly braces when arguments are supplied. Too many callbacks? Do I care when I can just type =>?

Generators

Generator functions (MDN) are ideal for creating functions that should be exited and continued later. They can make asynchronous APIs arguably cleaner, and are starting to be adopted by API designers for things that would be typically callback heavy, like database APIs.

Generator objects are both iterator and iterable: there's a whole section in the spec on iteration, but rather than puzzling over that if you want a solid technical introduction to iteration see Dr. Axel Rauschmayer's Iterables and iterators in ECMAScript 6.

Class syntax

Now you can make classes (MDN) the way you do in other languages. Kind of. Classes support subclassing (extend), and in derived classes you have to call super. Did you know that underneath the minimalist sheen of ES6 classes you'll find good old fashioned prototype chains?

The design of ES6 classes is mostly backwards compatible with existing code, so you don't need to rush around rewriting prototype classes as ES6 classes. However, like arrow functions and the new block scoping, using ES6 classes reduces boilerplate. You'll appreciate that fact when subclassing (there's no goofy constructor function .call, just call super).

Default and Rest Parameters

Speaking of boilerplate, did you know ES6 has default parameters (MDN) and rest (MDN) parameters?

You can now set defaults when defining arguments:

function f(a, b=123, c='a') { console.log(a, b, c); }  
f('a!');  

And here's a "rest" example:

function multiply(multiplier, ...theArgs) {  
  return theArgs.map(function (element) {
    return multiplier * element;
  });
}

var arr = multiply(2, 1, 2, 3);  
console.log(arr); // [2, 4, 6]  

More

Naturally there's a lot more that I don't have time to cover today: maps, weak maps, destructuring, modules, promises, proxies, typed arrays, template strings.

But of course, we're all using promises already! Template strings: grown up interpolation, extremely useful for everything from SQL statements to generating client-side HTML fragments.

Typed arrays relate to JavaScript evolving as a language for dealing with binary data: people have already been using and abusing them for making things like games, synthesisers, and graphics processing.

I saw this great tweet by Eric Elliott (retweeted by Marc Harter, my coauthor on Node.js in Practice) that linked the ES6 announcement with the news about WebAssembly:

WebAssembly, "wasm" for short, .wasm filename suffix, a new binary syntax for low-level safe code, initially co-expressive with asm.js, but in the long run able to diverge from JS's semantics, in order to best serve as common object-level format for multiple source-level programming languages.

It almost feels like JavaScript has changed overnight, except for the fact that ECMAScript 2015 has taken many years of hard work! It could have been more radical, but the standardisation process has kept it largely conservative and backwards compatible. It should also help us solve some of the issues JavaScript has as a language.

Now, if only those Node/io.js guys could get things all merged up so we can start using more ES6 features without having to transpile Node code...

Read the full article at: Add Styles to Console Statements

I was recently checking out Google Plus because they implement some awesome effects.  I opened the console and same the following message:

WARNING!

Using this console may allow attackers to impersonate you and steal your information using an attack called Self-XSS.

Do not enter or paste code that you do not understand.

I wasn’t surprised to see that message but what I did notice was that the text was red and the background was yellow.  The text was even a bit bigger.  How did they do it?  Pretty easily:

console.log("%c%s",
            "color: red; background: yellow; font-size: 24px;",
            "WARNING!");

The first argument is the order of style and message, the second is the style set, and the last is the desired message.

As to why you’d want to use this?  If it helps you identify debug information easier in the console, you may consider calling more attention to some messages!

Unit testing is an essential instrument in the toolbox of any serious software developer. However, it can sometimes be quite difficult to write a good unit test for a particular piece of code. Having difficulty testing their own or someone else’s code, developers often think that their struggles are caused by a lack of some fundamental testing knowledge or secret unit testing techniques.

In this article, I would like to show that unit testing itself is quite easy; the real problems that complicate unit testing, and introduce expensive complexity, are a result of poorly-designed, untestable code. We will discuss what makes code hard to test, which anti-patterns and bad practices we should avoid to improve testability, and what other benefits we can achieve by writing testable code. We will see that writing testable code is not just about making testing less troublesome, but about making the code itself more robust, and easier to maintain.

What is a Unit Test?

Essentially, a unit test is a method that instantiates a small portion of our application and verifies its behavior independently from other parts. A typical unit test contains 3 phases: First, it initializes a small piece of an application it wants to test (also known as the system under test, or SUT), then it applies some stimulus to the system under test (usually by calling a method on it), and finally, it observes the resulting behavior. If the observed behavior is consistent with the expectations, the unit test passes, otherwise, it fails, indicating that there is a problem somewhere in the system under test. These three unit test phases are also known as Arrange, Act and Assert, or simply AAA.

A unit test can verify different behavioral aspects of the system under test, but most likely it will fall into one of the following two categories: state-based or interaction-based. Verifying that the system under test produces correct results, or that its resulting state is correct, is called state-based unit testing, while verifying that it properly invokes certain methods is called interaction-based unit testing.

As a metaphor for a proper unit test, imagine a mad scientist who wants to build some supernatural chimera, with frog legs, octopus tentacles, bird wings, and a dog’s head. (This metaphor is pretty close to what programmers actually do at work). How would that scientist make sure that every part (or unit) he picked actually works? Well, he can take, let’s say, a single frog’s leg, apply an electrical stimulus to it, and check for proper muscle contraction. What he is doing is essentially the same Arrange-Act-Assert steps of the unit test; the only difference is that, in this case, unit refers to a physical object, not to an abstract object we build our programs from.

A simple unit test could look like this:

I will use C# for all examples in this article, but the concepts described apply to all object-oriented programming languages.

[TestMethod]
public void IsPalindrome_ForPalindromeString_ReturnsTrue()
{
    // In the Arrange phase, we create and set up a system under test.
    // A system under test could be a method, a single object, or a graph of connected objects.
    // It is OK to have an empty Arrange phase, for example if we are testing a static method -
    // in this case SUT already exists in a static form and we don't have to initialize anything explicitly.
    PalindromeDetector detector = new PalindromeDetector(); 

    // The Act phase is where we poke the system under test, usually by invoking a method.
    // If this method returns something back to us, we want to collect the result to ensure it was correct.
    // Or, if method doesn't return anything, we want to check whether it produced the expected side effects.
    bool isPalindrome = detector.IsPalindrome("kayak");

    // The Assert phase makes our unit test pass or fail.
    // Here we check that the method's behavior is consistent with expectations.
    Assert.IsTrue(isPalindrome);
}

Unit Tests vs. Integration Tests

Another important thing to consider is the difference between unit and integration tests.

The purpose of a unit test is to verify the behavior of a relatively small piece of software, independently from other parts. Unit tests are narrow in scope, and allow us to cover all cases, ensuring that every single part works correctly.

On the other hand, integration tests demonstrate that different parts of a system work together in the real-life environment. They validate complex scenarios (we can think of integration tests as a user performing some high-level operation within our system), and usually require external resources, like databases or web servers, to be present.

Let’s go back to our mad scientist metaphor, and suppose that he has successfully combined all the parts of the chimera. He wants to perform an integration test of the resulting creature, making sure that it can, let’s say, walk on different types of terrain. First of all, the scientist must emulate an environment for the creature to walk on. Then, he throws the creature into that environment and pokes it with a stick, observing if it walks and moves as designed. After finishing a test, the mad scientist cleans up all the dirt, sand and rocks that are now scattered in his lovely laboratory.

Notice the significant difference between unit and integration tests: A unit test verifies the behavior of small part of the application, isolated from the environment and other parts, and is quite easy to implement, while an integration test covers interactions between different components, in the close-to-real-life environment, and requires more effort, including additional setup and teardown phases.

A reasonable combination of unit and integration tests ensures that every single unit works correctly, independently from others, and that all these units play nicely when integrated, giving us a high level of confidence that the whole system works as expected. However, we must remember to always identify what kind of test we are implementing: a unit or an integration test. The difference can sometimes be deceiving. If we think we are writing a unit test to verify some subtle edge case in a business logic class, and realize that it requires external resources like web services or databases to be present, something is not right — essentially, we are using a sledgehammer to crack a nut. And that means bad design.

What Makes a Good Unit Test?

Before diving into the main part of this tutorial, let’s quickly discuss the properties of a good unit test. A good unit test should be:

• Easy to write. Developers typically write lots of unit tests to cover different cases and aspects of the application’s behavior, so it should be easy to code all of those test routines without enormous effort.

• Readable. The intent of a unit test should be clear. A good unit test tells a story about some behavioral aspect of our application, so it should be easy to understand which scenario is being tested and — if the test fails — easy to detect how to address the problem. With a good unit test, we can fix a bug without actually debugging the code!

• Reliable. Unit tests should fail only if there’s a bug in the system under test. That seems pretty obvious, but programmers often run into an issue when their tests fail even when no bugs were introduced. For example, tests may pass when running one-by-one, but fail when running the whole test suite, or pass on our development machine and fail on the continuous integration server. These situations are indicative of a design flaw. Good unit tests should be reproducible and independent from external factors such as the environment or running order.

• Fast. Developers write unit tests so they can repeatedly run them and check that no bugs have been introduced. If unit tests are slow, developers are more likely to skip running them on their own machines. One slow test won’t make a significant difference; add one thousand more and we’re surely stuck waiting for a while. Slow unit tests may also indicate that either the system under test, or the test itself, interacts with external systems, making it environment-dependent.

• Truly unit, not integration. As we already discussed, unit and integration tests have different purposes. Both the unit test and the system under test should not access the network resources, databases, file system, etc., to eliminate the influence of external factors.

That’s it — there are no secrets to writing unit tests. However, there are some techniques that allow us to write testable code.

Testable and Untestable Code

Some code is written in such a way that it is hard, or even impossible, to write a good unit test for it. So, what makes code hard to test? Let’s review some anti-patterns, code smells, and bad practices that we should avoid when writing testable code.

Poisoning the Codebase with Non-Deterministic Factors

Let’s start with a simple example. Imagine that we are writing a program for a smart home microcontroller, and one of the requirements is to automatically turn on the light in the backyard if some motion is detected there during the evening or at night. We have started from the bottom up by implementing a method that returns a string representation of the approximate time of day (“Night”, “Morning”, “Afternoon” or “Evening”):

public static string GetTimeOfDay()
{
    DateTime time = DateTime.Now;
    if (time.Hour >= 0 && time.Hour < 6)
    {
        return "Night";
    }
    if (time.Hour >= 6 && time.Hour < 12)
    {
        return "Morning";
    }
    if (time.Hour >= 12 && time.Hour < 18)
    {
        return "Afternoon";
    }
    return "Evening";
}

Essentially, this method reads the current system time and returns a result based on that value. So, what’s wrong with this code?

If we think about it from the unit testing perspective, we’ll see that it is not possible to write a proper state-based unit test for this method. DateTime.Now is, essentially, a hidden input, that will probably change during program execution or between test runs. Thus, subsequent calls to it will produce different results.

Such non-deterministic behavior makes it impossible to test the internal logic of the GetTimeOfDay() method without actually changing the system date and time. Let’s have a look at how such test would need to be implemented:

[TestMethod]
public void GetTimeOfDay_At6AM_ReturnsMorning()
{
    try
    {
        // Setup: change system time to 6 AM
        ...

        // Arrange phase is empty: testing static method, nothing to initialize

        // Act
        string timeOfDay = GetTimeOfDay();

        // Assert
        Assert.AreEqual("Morning", timeOfDay);
    }
    finally
    {
        // Teardown: roll system time back
        ...
    }
}

Tests like this would violate a lot of the rules discussed earlier. It would be expensive to write (because of the non-trivial setup and teardown logic), unreliable (it may fail even if there are no bugs in the system under test, due to system permission issues, for example), and not guaranteed to run fast. And, finally, this test would not actually be a unit test — it would be something between a unit and integration test, because it pretends to test a simple edge case but requires an environment to be set up in a particular way. The result is not worth the effort, huh?

Turns out that all these testability problems are caused by the low-quality GetTimeOfDay() API. In its current form, this method suffers from several issues:

• It is tightly coupled to the concrete data source. It is not possible to reuse this method for processing date and time retrieved from other sources, or passed as an argument; the method works only with the date and time of the particular machine that executes the code. Tight coupling is the primary root of most testability problems.

• It violates the Single Responsibility Principle (SRP). The method has multiple responsibilities; it consumes the information and also processes it. Another indicator of SRP violation is when a single class or method has more than one reason to change. From this perspective, the GetTimeOfDay() method could be changed either because of internal logic adjustments, or because the date and time source should be changed.

• It lies about the information required to get its job done. Developers must read every line of the actual source code to understand what hidden inputs are used and where they come from. The method signature alone is not enough to understand the method’s behavior.

• It is hard to predict and maintain. The behavior of a method that depends on a mutable global state cannot be predicted by merely reading the source code; it is necessary to take into account its current value, along with the whole sequence of events that could have changed it earlier. In a real-world application, trying to unravel all that stuff becomes a real headache.

After reviewing the API, let’s finally fix it! Fortunately, this is much easier than discussing all of its flaws — we just need to break the tightly coupled concerns.

Fixing the API: Introducing a Method Argument

The most obvious and easy way of fixing the API is by introducing a method argument:

public static string GetTimeOfDay(DateTime dateTime)
{    
    if (dateTime.Hour >= 0 && dateTime.Hour < 6)
    {
        return "Night";
    }
    if (dateTime.Hour >= 6 && dateTime.Hour < 12)
    {
        return "Morning";
    }
    if (dateTime.Hour >= 12 && dateTime.Hour < 18)
    {
        return "Noon";
    }
    return "Evening";
}

Now the method requires the caller to provide a DateTime argument, instead of secretly looking for this information by itself. From the unit testing perspective, this is great; the method is now deterministic (i.e., its return value fully depends on the input), so state-based testing is as easy as passing some DateTime value and checking the result:

[TestMethod]
public void GetTimeOfDay_For6AM_ReturnsMorning()
{
    // Arrange phase is empty: testing static method, nothing to initialize

    // Act
    string timeOfDay = GetTimeOfDay(new DateTime(2015, 12, 31, 06, 00, 00));

    // Assert
    Assert.AreEqual("Morning", timeOfDay);
}

Notice that this simple refactor also solved all the API issues discussed earlier (tight coupling, SRP violation, unclear and hard to understand API) by introducing a clear seam between what data should be processed and how it should be done.

Excellent — the method is testable, but how about its clients? Now it is the caller’s responsibility to provide date and time to the GetTimeOfDay(DateTime dateTime) method, meaning that they could become untestable if we don’t pay enough attention. Let’s have a look how we can deal with that.

Fixing the Client API: Dependency Injection

Say we continue working on the smart home system, and implement the following client of the GetTimeOfDay(DateTime dateTime) method — the aforementioned smart home microcontroller code responsible for turning the light on or off, based on the time of day and the detection of motion:

public class SmartHomeController
{
    public DateTime LastMotionTime { get; private set; }

    public void ActuateLights(bool motionDetected)
    {
        DateTime time = DateTime.Now; // Ouch!

        // Update the time of last motion.
        if (motionDetected)
        {
            LastMotionTime = time;
        }
        
        // If motion was detected in the evening or at night, turn the light on.
        string timeOfDay = GetTimeOfDay(time);
        if (motionDetected && (timeOfDay == "Evening" || timeOfDay == "Night"))
        {
            BackyardLightSwitcher.Instance.TurnOn();
        }
        // If no motion is detected for one minute, or if it is morning or day, turn the light off.
        else if (time.Subtract(LastMotionTime) > TimeSpan.FromMinutes(1) || (timeOfDay == "Morning" || timeOfDay == "Noon"))
        {
            BackyardLightSwitcher.Instance.TurnOff();
        }
    }
}

Ouch! We have the same kind of hidden DateTime.Now input problem — the only difference is that it is located on a little bit higher of an abstraction level. To solve this issue, we can introduce another argument, again delegating the responsibility of providing a DateTime value to the caller of a new method with signature ActuateLights(bool motionDetected, DateTime dateTime). But, instead of moving the problem a level higher in the call stack once more, let’s employ another technique that will allow us to keep both ActuateLights(bool motionDetected) method and its clients testable: Inversion of Control, or IoC.

Inversion of Control is a simple, but extremely useful, technique for decoupling code, and for unit testing in particular. (After all, keeping things loosely coupled is essential for being able to analyze them independently from each other.) The key point of IoC is to separate decision-making code (when to do something) from action code (what to do when something happens). This technique increases flexibility, makes our code more modular, and reduces coupling between components.

Inversion of Control can be implemented in a number of ways; let’s have a look at one particular example — Dependency Injection using a constructor — and how it can help in building a testable SmartHomeController API.

First, let’s create an IDateTimeProvider interface, containing a method signature for obtaining some date and time:

public interface IDateTimeProvider
{
    DateTime GetDateTime();
}

Then, make SmartHomeController reference an IDateTimeProvider implementation, and delegate it the responsibility of obtaining date and time:

public class SmartHomeController
{
    private readonly IDateTimeProvider _dateTimeProvider; // Dependency

    public SmartHomeController(IDateTimeProvider dateTimeProvider)
    {
        // Inject required dependency in the constructor.
        _dateTimeProvider = dateTimeProvider;
    }

    public void ActuateLights(bool motionDetected)
    {
        DateTime time = _dateTimeProvider.GetDateTime(); // Delegating the responsibility

        // Remaining light control logic goes here...
    }
}

Now we can see why Inversion of Control is so called: the control of what mechanism to use for reading date and time was inverted, and now belongs to the client of SmartHomeController, not SmartHomeController itself. Thereby, the execution of the ActuateLights(bool motionDetected) method fully depends on two things that can be easily managed from the outside: the motionDetected argument, and a concrete implementation of IDateTimeProvider, passed into a SmartHomeController constructor.

Why is this significant for testing? It means that different IDateTimeProvider implementations can be used in production code and unit test code. In the production environment, some real-life implementation will be injected (e.g., one that reads actual system time). In the unit test, however, we can inject a “fake” implementation that returns a constant or predefined DateTime value suitable for testing the particular scenario.

A fake implementation of IDateTimeProvider could look like this:

public class FakeDateTimeProvider : IDateTimeProvider
{
    public DateTime ReturnValue { get; set; }

    public DateTime GetDateTime() { return ReturnValue; }

    public FakeDateTimeProvider(DateTime returnValue) { ReturnValue = returnValue; }
}

With the help of this class, it is possible to isolate SmartHomeController from non-deterministic factors and perform a state-based unit test. Let’s verify that, if motion was detected, the time of that motion is recorded in the LastMotionTime property:

[TestMethod]
void ActuateLights_MotionDetected_SavesTimeOfMotion()
{
    // Arrange
    var controller = new SmartHomeController(new FakeDateTimeProvider(new DateTime(2015, 12, 31, 23, 59, 59)));

    // Act
    controller.ActuateLights(true);

    // Assert
    Assert.AreEqual(new DateTime(2015, 12, 31, 23, 59, 59), controller.LastMotionTime);
}

Great! A test like this was not possible before refactoring. Now that we’ve eliminated non-deterministic factors and verified the state-based scenario, do you think SmartHomeController is fully testable?

Poisoning the Codebase with Side Effects

Despite the fact that we solved the problems caused by the non-deterministic hidden input, and we were able to test certain functionality, the code (or, at least, some of it) is still untestable!

Let’s review the following part of the ActuateLights(bool motionDetected) method responsible for turning the light on or off:

// If motion was detected in the evening or at night, turn the light on.
if (motionDetected && (timeOfDay == "Evening" || timeOfDay == "Night"))
{
    BackyardLightSwitcher.Instance.TurnOn();
}
// If no motion was detected for one minute, or if it is morning or day, turn the light off.
else if (time.Subtract(LastMotionTime) > TimeSpan.FromMinutes(1) || (timeOfDay == "Morning" || timeOfDay == "Noon"))
{
    BackyardLightSwitcher.Instance.TurnOff();
}

As we can see, SmartHomeController delegates the responsibility of turning the light on or off to a BackyardLightSwitcher object, which implements a Singleton pattern. What’s wrong with this design?

To fully unit test the ActuateLights(bool motionDetected) method, we should perform interaction-based testing in addition to the state-based testing; that is, we should ensure that methods for turning the light on or off are called if, and only if, appropriate conditions are met. Unfortunately, the current design does not allow us to do that: the TurnOn() and TurnOff() methods of BackyardLightSwitcher trigger some state changes in the system, or, in other words, produce side effects. The only way to verify that these methods were called is to check whether their corresponding side effects actually happened or not, which could be painful.

Indeed, let’s suppose that the motion sensor, backyard lantern, and smart home microcontroller are connected into an Internet of Things network and communicate using some wireless protocol. In this case, a unit test can make an attempt to receive and analyze that network traffic. Or, if the hardware components are connected with a wire, the unit test can check whether the voltage was applied to the appropriate electrical circuit. Or, after all, it can check that the light actually turned on or off using an additional light sensor.

As we can see, unit testing side-effecting methods could be as hard as unit testing non-deterministic ones, and may even be impossible. Any attempt will lead to problems similar to those we’ve already seen. The resulting test will be hard to implement, unreliable, potentially slow, and not-really-unit. And, after all that, the flashing of the light every time we run the test suite will eventually drive us crazy!

Again, all these testability problems are caused by the bad API, not the developer’s ability to write unit tests. No matter how exactly light control is implemented, the SmartHomeController API suffers from these already-familiar issues:

• It is tightly coupled to the concrete implementation. The API relies on the hard-coded, concrete instance of BackyardLightSwitcher. It is not possible to reuse the ActuateLights(bool motionDetected) method to switch any light other than the one in the backyard.

• It violates the Single Responsibility Principle. The API has two reasons to change: First, changes to the internal logic (such as choosing to make the light turn on only at night, but not in the evening) and second, if the light-switching mechanism is replaced with another one.

• It lies about its dependencies. There is no way for developers to know that SmartHomeController depends on the hard-coded BackyardLightSwitcher component, other than digging into the source code.

• It is hard to understand and maintain. What if the light refuses to turn on when the conditions are right? We could spend a lot of time trying to fix the SmartHomeController to no avail, only to realize that the problem was caused by a bug in the BackyardLightSwitcher (or, even funnier, a burned out lightbulb!).

The solution of both testability and low-quality API issues is, not surprisingly, to break tightly coupled components from each other. As with the previous example, employing Dependency Injection would solve these issues; just add an ILightSwitcher dependency to the SmartHomeController, delegate it the responsibility of flipping the light switch, and pass a fake, test-only ILightSwitcher implementation that will record whether the appropriate methods were called under the right conditions. However, instead of using Dependency Injection again, let’s review an interesting alternative approach for decoupling the responsibilities.

Fixing the API: Higher-Order Functions

This approach is an option in any object-oriented language that supports first-class functions. Let’s take advantage of C#’s functional features and make the ActuateLights(bool motionDetected) method accept two more arguments: a pair of Action delegates, pointing to methods that should be called to turn the light on and off. This solution will convert the method into a higher-order function:

public void ActuateLights(bool motionDetected, Action turnOn, Action turnOff)
{
    DateTime time = _dateTimeProvider.GetDateTime();
    
    // Update the time of last motion.
    if (motionDetected)
    {
        LastMotionTime = time;
    }
    
    // If motion was detected in the evening or at night, turn the light on.
    string timeOfDay = GetTimeOfDay(time);
    if (motionDetected && (timeOfDay == "Evening" || timeOfDay == "Night"))
    {
        turnOn(); // Invoking a delegate: no tight coupling anymore
    }
    // If no motion is detected for one minute, or if it is morning or day, turn the light off.
    else if (time.Subtract(LastMotionTime) > TimeSpan.FromMinutes(1) || (timeOfDay == "Morning" || timeOfDay == "Noon"))
    {
        turnOff(); // Invoking a delegate: no tight coupling anymore
    }
}

This is a more functional-flavored solution than the classic object-oriented Dependency Injection approach we’ve seen before; however, it lets us achieve the same result with less code, and more expressiveness, than Dependency Injection. It is no longer necessary to implement a class that conforms to an interface in order to supply SmartHomeController with the required functionality; instead, we can just pass a function definition. Higher-order functions can be thought of as another way of implementing Inversion of Control.

Now, to perform an interaction-based unit test of the resulting method, we can pass easily verifiable fake actions into it:

[TestMethod]
public void ActuateLights_MotionDetectedAtNight_TurnsOnTheLight()
{
    // Arrange: create a pair of actions that change boolean variable instead of really turning the light on or off.
    bool turnedOn  = false;
    Action turnOn  = () => turnedOn = true;
    Action turnOff = () => turnedOn = false;
    var controller = new SmartHomeController(new FakeDateTimeProvider(new DateTime(2015, 12, 31, 23, 59, 59)));

    // Act
    controller.ActuateLights(true, turnOn, turnOff);

    // Assert
    Assert.IsTrue(turnedOn);
}

Finally, we have made the SmartHomeController API fully testable, and we are able to perform both state-based and interaction-based unit tests for it. Again, notice that in addition to improved testability, introducing a seam between the decision-making and action code helped to solve the tight coupling problem, and led to a cleaner, reusable API.

Now, in order to achieve full unit test coverage, we can simply implement a bunch of similar-looking tests to validate all possible cases — not a big deal since unit tests are now quite easy to implement.

Impurity and Testability

Uncontrolled non-determinism and side effects are similar in their destructive effects on the codebase. When used carelessly, they lead to deceptive, hard to understand and maintain, tightly coupled, non-reusable, and untestable code.

On the other hand, methods that are both deterministic and side-effect-free are much easier to test, reason about, and reuse to build larger programs. In terms of functional programming, such methods are called pure functions. We’ll rarely have a problem unit testing a pure function; all we have to do is to pass some arguments and check the result for correctness. What really makes code untestable is hard-coded, impure factors that cannot be replaced, overridden, or abstracted away in some other way.

Impurity is toxic: if method Foo() depends on non-deterministic or side-effecting method Bar(), then Foo() becomes non-deterministic or side-effecting as well. Eventually, we may end up poisoning the entire codebase. Multiply all these problems by the size of a complex real-life application, and we’ll find ourselves encumbered with a hard to maintain codebase full of smells, anti-patterns, secret dependencies, and all sorts of ugly and unpleasant things.

However, impurity is inevitable; any real-life application must, at some point, read and manipulate state by interacting with the environment, databases, configuration files, web services, or other external systems. So instead of aiming to eliminate impurity altogether, it’s a good idea to limit these factors, avoid letting them poison your codebase, and break hard-coded dependencies as much as possible, in order to be able to analyze and unit test things independently.

Common Warning Signs of Hard to Test Code

Trouble writing tests? The problem's not in your test suite. It's in your code.

Finally, let’s review some common warning signs indicating that our code might be difficult to test.

Static Properties and Fields

Static properties and fields or, simply put, global state, can complicate code comprehension and testability, by hiding the information required for a method to get its job done, by introducing non-determinism, or by promoting extensive usage of side effects. Functions that read or modify mutable global state are inherently impure.

For example, it is hard to reason about the following code, which depends on a globally accessible property:

if (!SmartHomeSettings.CostSavingEnabled) { _swimmingPoolController.HeatWater(); }

What if the HeatWater() method doesn’t get called when we are sure it should have been? Since any part of the application might have changed the CostSavingEnabled value, we must find and analyze all the places modifying that value in order to find out what’s wrong. Also, as we’ve already seen, it is not possible to set some static properties for testing purposes (e.g., DateTime.Now, or Environment.MachineName; they are read-only, but still non-deterministic).

On the other hand, immutable and deterministic global state is totally OK. In fact, there’s a more familiar name for this — a constant. Constant values like Math.PI do not introduce any non-determinism, and, since their values cannot be changed, do not allow any side effects:

double Circumference(double radius) { return 2 * Math.PI * radius; } // Still a pure function!

Singletons

Essentially, the Singleton pattern is just another form of the global state. Singletons promote obscure APIs that lie about real dependencies and introduce unnecessarily tight coupling between components. They also violate the Single Responsibility Principle because, in addition to their primary duties, they control their own initialization and lifecycle.

Singletons can easily make unit tests order-dependent because they carry state around for the lifetime of the whole application or unit test suite. Have a look at the following example:

User GetUser(int userId)
{
    User user;
    if (UserCache.Instance.ContainsKey(userId))
    {
        user = UserCache.Instance[userId];
    }
    else
    {
        user = _userService.LoadUser(userId);
        UserCache.Instance[userId] = user;
    }
    return user;
}

In the example above, if a test for the cache-hit scenario runs first, it will add a new user to the cache, so a subsequent test of the cache-miss scenario may fail because it assumes that the cache is empty. To overcome this, we’ll have to write additional teardown code to clean the UserCache after each unit test run.

Using Singletons is a bad practice that can (and should) be avoided in most cases; however, it is important to distinguish between Singleton as a design pattern, and a single instance of an object. In the latter case, the responsibility of creating and maintaining a single instance lies with the application itself. Typically, this is handed with a factory or Dependency Injection container, which creates a single instance somewhere near the “top” of the application (i.e., closer to an application entry point) and then passes it to every object that needs it. This approach is absolutely correct, from both testability and API quality perspectives.

The new Operator

Newing up an instance of an object in order to get some job done introduces the same problem as the Singleton anti-pattern: unclear APIs with hidden dependencies, tight coupling, and poor testability.

For example, in order to test whether the following loop stops when a 404 status code is returned, the developer should set up a test web server:

using (var client = new HttpClient())
{
    HttpResponseMessage response;
    do
    {
        response = await client.GetAsync(uri);
        // Process the response and update the uri...
    } while (response.StatusCode != HttpStatusCode.NotFound);
}

However, sometimes new is absolutely harmless: for example, it is OK to create simple entity objects:

var person = new Person("John", "Doe", new DateTime(1970, 12, 31));

It is also OK to create a small, temporary object that does not produce any side effects, except to modify their own state, and then return the result based on that state. In the following example, we don’t care whether Stack methods were called or not — we just check if the end result is correct:

string ReverseString(string input)
{
    // No need to do interaction-based testing and check that Stack methods were called or not;
    // The unit test just needs to ensure that the return value is correct (state-based testing).
    var stack = new Stack<char>();
    foreach(var s in input)
    {
        stack.Push(s);
    }
    string result = string.Empty;
    while(stack.Count != 0)
    {
        result += stack.Pop();
    }
    return result;
}

Static Methods

Static methods are another potential source of non-deterministic or side-effecting behavior. They can easily introduce tight coupling and make our code untestable.

For example, to verify the behavior of the following method, unit tests must manipulate environment variables and read the console output stream to ensure that the appropriate data was printed:

void CheckPathEnvironmentVariable()
{

    if (Environment.GetEnvironmentVariable("PATH") != null)
    {
        Console.WriteLine("PATH environment variable exists.");
    }

    else
    {
       Console.WriteLine("PATH environment variable is not defined.");
    }

}

However, pure static functions are OK: any combination of them will still be a pure function. For example:

double Hypotenuse(double side1, double side2) { return Math.Sqrt(Math.Pow(side1, 2) + Math.Pow(side2, 2)); }

Conclusion

Obviously, writing testable code requires some discipline, concentration, and extra effort. But software development is a complex mental activity anyway, and we should always be careful, and avoid recklessly throwing together new code from the top of our heads.

As a reward, we’ll end up with clean, easy-to-maintain, loosely coupled, and reusable APIs, that won’t damage developers’ brains when they try to understand it. After all, the ultimate advantage of testable code is not only the testability itself, but the ability to easily understand, maintain and extend that code as well.

---

Building your design portfolio? Here are 8 things I wish I’d known.

Two years ago, I was finishing my last semester of college, and preparing for the seminal moment in a design student’s life: portfolio reviews, and finding a job. And even though I was finishing a degree in graphic design, I was looking for a full-time job as a UX/UI Designer.

My hard work paid off. I landed a job at Bloc, and it’s been a magical time.

But, it was a painful process. I got a lot of rejection emails, and made a lot of mistakes. Now that I’m building a company that creates new UX Designers on a daily basis, I can look back at my old portfolio and pass on those lessons learned. Here are 8 things that I got right and wrong.

1. Present your work as a case study.

Fill your portfolio with as many case studies as possible.

When I applied to jobs in college, I filled my portfolio with big, beautiful visuals. I applied to UX/UI jobs left and right, with no luck. “Why? What am I doing wrong?”

I asked a friend for help — and she passed along a few portfolios of friends that’d gotten hired at top tier companies and…

They all had case studies. Rich, wonderful case studies that talked about their design process, their successes and failures, and their ultimate design solutions.

I thought, Why couldn’t I have case studies?

So I added case studies. And, success. My employer response rate jumped.

Big beautiful images look great, but they don’t tell a hiring manager if you can solve a problem. Can you design a solution that makes your users, clients, and stakeholders happy? Can you talk about your process — what solutions you tried, what worked, what didn’t, and why? Can you show heaps of work including prototypes, wireframes, scrapped visuals that shows your rigorous problem solving skills?

Show that you can solve problems, and you’ll show that you’re worth hiring.

2. Carefully curate your portfolio

Should your portfolio be specialized, or general? Design student, this choice is tough. Some educators advise to diversify your portfolio: show a variety of work — be it packaging, print, advertising, and web. Others encourage to specialize. You like mobile apps? You want to build mobile apps in the future? Fill your portfolio with mobile apps.

If you’re still exploring careers, and you’re not sure what you’d like to do, I say that it’s good to show breadth. But if you want to design mobile apps, and only design mobile apps — then specialize, specialize, specialize. The majority of work in your portfolio should be that specialty.

When I was starting out, I wanted to do UI design, so I applied for UI positions. My portfolio was filled with web or mobile interface design. But here’s the secret: my entire body of work over the past three years wasn’t all web — over half of it was print. But I didn’t want a print job, so I omitted it. And I got the job I wanted.

3. Showcase real-world work, even if it’s got problems.

In school, I had an excellent internship. I designed beautiful work — and my team was thrilled with it. I left my internship proud and pleased. But shortly after, the project fell apart, and my team disbanded — partially because of the work I did!

Awkward. The work looked great, but the project ultimately failed. Should I put it in my portfolio, even though I’d have to talk about it to future employers?

I put it in my portfolio.

And man, it was awkward: during interviews, I presented a project that I ultimately failed on. But, being honest about failure was an asset. I spoke frankly about how the project succeeded, and how it failed. I talked about what could be better. I showed that I tried, and learned. And that went over well with the designers I spoke with.

When a designer interviews you, they don’t know what it’s like to work with you…until they do work with you. So as a substitute, show that you‘ve worked with others. This real-world experience demonstrates your character — it shows that you can work with a team of stakeholders, under tough deadlines and constraints. And if that project has a poor outcome, talking about it is good. You’re not ashamed of the un-sexy work you’ve created, but you’re smart to be critical of the outcome.

4. Less design exercises. More in-depth case studies.

Portfolio one: typography poster, ad for hypothetical product, Reddit redesign.

Portfolio two: ad for hypothetical product, Facebook redesign, concert poster.

Portfolio three: Craigslist redesign, fake mobile app, fake ad campaign.

Go through hundreds of portfolios, and it’s not that hard to spot class projects.

Let me be clear: posters from your first-year typography class look cool! But they don’t show that you can work independently, and solve problems — they show that you can follow a prompt. If you choose to showcase design exercises in your portfolio, make sure those exercises involve rigorous problem solving, and make ‘em case studies!

5. Talk about results.

I was interviewing for an internship.

I completed a design exercise for the firm, and I was explaining my concept to the interviewer. I’d designed a flashy, interactive wireframe with tons of features, and as I finished up my sentence, I felt proud and confident.

And then the interviewer asked, “What goals are you trying to accomplish with this design?”

I stammered out a reiteration of the prompt they’d given me.

The interviewer paused. I balked. Needless to say, I didn’t get the internship.

I love seeing beautiful, entertaining interaction design work. I spend hours drooling over the layouts on Site Inspire. But I know this from my own work: if your design doesn’t improve the user’s experience, solve the business goals, or whatever outcome you set, it’s purely decorative and useless.

Talk about results. Get real data if you can. But if you can’t — and it’s hard for student projects — interview your users or stakeholders to get a grip on whether or not your design achieves it’s outcomes. Always start and end a project with a goal and an outcome.

6. Make your portfolio easy to navigate

Today, I have to conduct user interviews, meet with stakeholders, design a sticker, approve a UI change, prototype some concepts for a new feature, and review the last 20 resumes that’ve come in.

I have to quickly separate the good portfolios from the bad.

I have — at best — 2 minutes per portfolio.

I’ve seen beautiful, neat, innovative work. I’ve seen designers experiment with interesting layouts, and wonderful site designs. But if I find myself lost — if I can’t navigate your site quickly and easily, I’m frustrated.

Make sure a user can move through your portfolio quickly and with ease. Make sure it’s easy to browse on mobile! If the user experience of your portfolio isn’t as good as the user experience of your work, it doesn’t reflect well on your talent as a designer.

And yes — make sure your portfolio is online!

7. Do your research, and write sincerely.

I received an excellent email application from a designer.

Sincere, succinct, straight to the point — she showed that she had a passion for education, aligned with our mission, and threw in a dash of humor, to boot.

I set up an interview the next day. And in time, she got the job.

A hiring manager reads hundreds of cover emails. The majority start with “Dear Hiring Manager…”, outline the applicant’s experience in excessive, flowery speech, and usually end with the candidate being “fully aligned with your mission.”

Ditch the cover letter. Show you’re a passionate, excellent designer through that first email — it’s much more effective than a template. Talk about problems you’ve tackled in the company’s industry. Show that you know the company inside and out. Show that you really, truly care.

Be brief, but be sincere — it shows through in a sea of templates.

8. Let your passion show.

In my first interview with Bloc, I went on a ten minute rant about design education, the value of self-driven learning, the difficulties of being self-taught, growing needs in the design community, new tools I was trying… and I looked up, embarrassed about running my mouth for a few minutes.

But, that’s passion.

The design community changes and grows. Showing that you’re passionate about the industry and the company… that really shows good character.

Talk about what you’re interested in. Get involved in the community, online or in-person. Share links, start discussions, write about your field of interest. Contribute, even if you’re still learning.

And let that passion shine!

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers.

آغاز خلقت دنیا

1- حضرت رسول اکرم (صلّی الله علیه و آله و سلّم) فرمودند: حضرت موسی در پیشگاه الهی از آغاز دنیا سوال کرد و گفت چه مدت است که آن را آفریده ای. خداوند فرمود: از مشکلات علم من می پرسی ؟ گفت پروردگارا دوست دارم این حقیقت را بدانم. فرمود: از آفرینش دنیا صد هزار هزار سال که ده برابر تکرار شود گذشته است. این عدد همان است که امروز آن را میلیارد می خوانند.

منبع : بحار 14،ص81

2- حضرت امام علی (علیه السّلام) فرمودند:  دنیا سرای راستی است برای کسی که آن را به راستی و درستی تلقی نماید، خانه ی ایمنی و سلامت است برای کسی که آن را به درستی درک کند، جایگاه توانگری است برای کسیکه از آن توشه بردارد ، سرای موعظه است برای کسیکه از آن پند گیرد، سجده گاه دوستان خدا و نماز خانه ی فرشتگان الهی است، محل نزول وحی پروردگار و تجارتخانه ی دوستداران حضرت حق است، در آن به کسب رحمت الهی پرداختند و سودی که نصیبشان گردید بهشت جاودان است.

منبع : نهج البلاغه ، کلمه ی 126

3- حضرت امام علی (علیه السّلام) فرمودند:  مجموع عمر آدمی در دنیا ساعتی بیش نیست آنچه از این ساعت گذشته است معدوم شده و لذّت و اَلَمی از آن احساس نمی کنید و آنچه هنوز از آن نیامده است نمی دانید چیست، سرمایه ی موجود و پر ارزش عمر ، تنها همان لحظات نقدی است که اینک در اختیار شما است و در آن به سر می برید. مالک نفس خود باشید و در حال حاضر برای اصلاح و رستگاری خود بکوشید، در مشکلات وظیفه شناسی و اطاعت از اوامر الهی و از آلودگی به گناه و نافرمانی خداوند، خودداری کنید.

منبع : کافی 2 ،ص454

4- حضرت امام علی (علیه السّلام) فرمودند: دنیا برای تو دو روز است. یک روز به نفع تو و طبق تمایلات تو است و یک روز به ضرر تو و بر خلاف خواهش های تو است. روزی که به نفع تو است و نعم الهی را در اختیار داری طغیان و سرکشی منما، و روزی که به ضرر تو است و گرفتار ناملائماتی ،صابر و بردبار باش.

منبع : نهج البلاغه ،کلمه ی 390

5- حضرت امام علی (علیه السّلام) فرمودند: چه نزدیک است دنیا را گذران و رفتن و چه نزدیک است جوانی را ، پیری و درهم شکستن.

منبع : غررالحکم ،ص754

6- حضرت امام علی (علیه السّلام) در ضمن نامه ای که به عبدالله بن عبّاس نوشته فرموده اند: نسبت به چیزی که از دنیایت فوت شده و از دست داده ای غمگین و بی تاب مباش.

منبع : نهج البلاغه فیض ،ص864 و 1265

7- حضرت امام علی (علیه السّلام) فرمودند: غم و اندوه سال نیامده را بر امروز خود تحمیل منما که هر روزی هر آنچه در آن هست برای تو کافی است .

منبع : نهج البلاغه فیض ،ص864 و 1265

8- حضرت امام علی (علیه السّلام) فرموده اند: ای مردم جهان، دنیا سرای گذران و آخرت منزل جاویدان است. شما از دنیائی که رهگذر شما است برای قرارگاه خود ذخیره ای اندوزید و سرمایه ای بردارید.

منبع : نهج البلاغه ،خطبه ی 194

9- حضرت امام سجاد (علیه السّلام) فرموده اند: کسی که به کرامت نفس و شخصیت روحانی نائل آمده است مادیات پست، نزد او حقیر و ناچیز است.

منیع :  تحف العقول ص 278

10- حضرت امام موسی کاظم (علیه السّلام) فرموده اند: از ما نیست و به ما بستگی روحانی ندارد آنکس که دنیای خود را برای دینش یا دین خود را برای دنیای خویش ترک گوید.

منبع : بحار جلد 17، ص208

11- حضرت امام صادق (علیه السّلام) فرموده اند: ایّام زندگی سه روز است: اوّل روزیکه گذشته است و برگشت ندارد، دوّم روز موجود است که مردم در آن قرار دارند و در اختیار آنهاست ، باید آن را مغتنم شمارند و از آن استفاده نمایند ، سوّم فردایی است که نیامده و تنها آرزوی آن را در دست دارند.

منبع : تحف العقول ،ص324

دنیا پرستها

12- حضرت امام علی (علیه السّلام) فرموده اند: محبّت دنیا عقل را فاسد می کند و گوش دل را از شنیدن مطالب حکیمانه ناشنوا میسازد.

منبع : فهرست غرر،ص111

13- حضرت امام صادق (علیه السّلام) فرموده اند: کسیکه به دنیا دل بسته و در بند علاقه اش اسیر است همواره گرفتار سه حالت روحی است: غصّه و اندوهی که هرگز از صفحه ی دلش زدوده نمی شود، آرزوئی که هرگز برآورده نمی گردد، و امیدی که هرگز به آن دست نمی یابد.

منبع : کافی ، جلد 2،ص320

14- محمّد بن مسلم زهری از مردان فهمیده و تحصیل کرده ای بود که تمایل مال و مقام، از مسیر پاکی و فضیلت منحرفش ساخت و در کبر سن دچار تیره روزی و بدبختی شد. حضرت علی بن الحسین (علیه السّلام) به منظور راهنمایی و نصیحت ، نامه ای به وی نوشته و در ضمن یک جمله ی کوتاه، نارسایی فکر جوانان و خطرات بیشتری را که بر سر راه آنان وجود دارد خاطر نشان فرموده اند: وقتی که دنیا پرستی می تواند مانند تو کسی را تا این درجه به انحطاط و پستی برساند با آنکه عمر بسیار کرده ای و از تحصیلات عمیق علمی بهره مند شده ای و با مرگ فاصله ی زیادی نداری پس یک نفر جوان در برابر تمایلات نفسانی خود چگونه سالم می ماند، جوانی که نوخاسته و از دانش بی بهره است، جوانی که رأیش ضعیف و عقلش نارسا و منحرف است؟

منبع : تحف العقول ،ص277

15- حضرت امام علی (علیه السّلام) فرموده اند: کسیکه در مقابل شیفتگان دنیا اظهار ذلّت کند و برای دلباختگان مال و مقام تن به خواری بدهد با این عمل، جامه ی تقوی و پاکی را از بر خود بدر آورده است.

منبع : فهرس غرر ،ص126

16- خداوند به داود پیغمبر وحی فرستاد: درباره ی عالمی که علائق دنیوی و شهوات مادّی او را مست کرده است از من پرسش مکن ، اینان راهزنانی بر بندگان من هستند.

منبع : لئالی الاخبار ص 192

دنیای مشروع

17- حضرت امام رضا (علیه السّلام) فرموده اند: از لذایذ  دنیوی نصیبی برای کامیابی خویش قرار دهید وتمنیات دل را از راههای مشروع برآورید، مراقبت کنید در این کار بمردانگی و شرافتتان آسیب نرسد و دچار اسراف و تندروی نشوید. تفریح و سرگرمیهای لذت بخش شما را در اداره زندگی یاری میکند و با کمک آن بهتر به امور دنیای خویش موفق خواهید شد.

منبع:بحار17،صفحه208

18- مردی با نگرانی به حضرت امام صادق (علیه السّلام)عرض کرد: به خدا قسم ما سخت گرفتار دنیا طلبی شده ایم و دوست داریم که بر مال و ذخائر آن دست یابیم وضع ما چگونه خواهد بود ؟ حضرت از او سؤال کرد دوست داری با مال دنیا چه کنی و درآمدت را در چه راهی صرف نمائی؟ جواب داد: 1- قسمتی را در بهبود زندگبی خود و عائله صرف نایم. 2- صله رحم کنم و به بستگان تهیدستم کمک نمایم. 3- در راه خدا به فقرا و مستمندان بدهم. 4- به سفر عبادت حج و عمره بروم . حضرت فرمودند: نگران نباش  کار تو دنیا طلبی مذموم نیست بلکه این کار خود آخرت طلبی است.

منبع : کافی 5 ،ص72

19- عمرو بن جمیع می گوید از حضرت امام صادق (علیه السّلام) شنیدم که می فرمودند: خیر وخوبی در آنکس نیست که دوستدار جمع آوری مال حلال نباشد تا بدان وسیله آبروی خود را از ذلت سؤال مصون بدارد و دین خویش را بپردازد و به ارحام فقیر خود کمک نماید.

منبع : کافی 5 ،ص72

بازار دنیا

20- حضرت امام علی (علیه السّلام) فرموده اند: دنیای گذران چشم انداز نهائی کوردل و ناآگاه است و عوالم بعد از آن را نمی بیند. اما انسان بصیر و بینا آینده را هم می نگرد و می داند مقرّ ثابت و خانه ی دائمی انسان در وراءِ این جهان است. انسان بصیر از دیدگاه دنیا به عالم بعد از مرگ نیز توجه دارد و فاقد بصیرت، تنها به دنیا چشم دوخته است. انسان بصیر از این منزل برای منازل بعد از مرگ، ذخیره و زاد تهیه می کند و کوردل فقط برای دنیا توشه بر میدارد.

منبع : نهج البلاغه ،خطبه 133

21- حضرت امام محمدباقر (علیه السّلام) فرموده اند: دنیا بازاری از بازار ها است. گروهی از این بازار خارج می شوند، کالای نافع و سود بخش می برند و بعضی با متاع مضر و زیانبار از این بازار بیرون می آیند.

منبع : بحار ،جلد17،ص

22- حضرت امام هادی (علیه السّلام) فرموده اند: دنیا بازاری است که گروهی در آن نفع می برند و گروهی ضرر می بینند.

منبع : تف العقول ، ص483

حبّ دنیا

23- حضرت رسول خدا (صلّی الله علیه و آله و سلّم) فرمودند: چه شده است مرا که می بینم حبّ دنیا بر بسیاری از مردم غلبه کرده و آن چنان شده اند که گویی مرگ در این عالم برای غیر آنان مقدّر گردیده است و رعایت حق و عدل بر کسان دیگری واجب شده است. و به طوری از واقع بینی بازمانده اند که وقتی خبر مرگ پیشینیان را می شنوند در نظرشان همانند مردمانی می آید که به سفر رفته اند و طولی نمی کشد که باز می گردند.

منبع : سفینه ،جلد1 ،سوق،ص674

مسوولیت های اجتماعی

24- حضرت امام علی (علیه السّلام) فرموده اند: سوگند به خدایی که دانه را شکافت و جان را آفرید، اگر حضور فراوان بیعت کنندگان نبود، و یاران حجّت را بر من تمام نمی کردند، و اگر خداوند از علماء عهد و پیمان نگرفته بود که برابر شکم بارگیِ ستمگران و گرسنگی مظلومان، سکوت نکنند، مهار شتر خلافت را بر کوهان آن انداخته، رهایش می ساختیم، و آخر خلافت را به کاسه ی اول آن سیراب می کردم، آنگاه می دیدیدکه دنیای شما نزد من از آب بینی بزغاله ای بی ارزش تر است.⁽¹⁾ گفتند: در اینجا مردی از اهالی عراق بلند شد ونامه ای به دست امام(علیه السّلام) داد و امام(علیه السّلام) آن را مطالعه می فرمود، گفته شد مسائلی در آن بود که می بایست جواب می داد. وقتی خواندن نامه به پایان رسید، ابن عباس گفت یا امیرالمومنین! چه خوب بود سخن را از همان جا که قطع شد آغاز می کردید؟ امام(علیه السّلام) فرمود: هرگز! ای پسر عباس، شعله ای از آتش دل بود، زبانه کشید، و فرو نشست،  ابن عباس می گوید، به خدا سوگند! بر هیچ گفتاری مانند قطع شدن سخن امام(علیه السّلام) این گونه اندوهناک نشدم، که امام نتوانست تا آنجا که دوست دارد به سخن ادامه دهد.

منبع: نهج البلاغه، خطبه 3

دنیا شناسی

25- حضرت امام علی (علیه السّلام) فرموده اند: پس از حمد وستایش الهی؛ همانا دنیا روی گردانده، و وداع خویش را اعلام داشته است، و آخرت به ما روی آورده، و پیشروان لشکرش نمایان شده.آگاه باشید! امروز، روز تمرین و آمادگی، و فردا روز مسابقه است، پاداش برندگان، بهشت، وکیفر عقب ماندگان آتش است.آیا کسی هست که پیش از مرگ، از اشتباهات خود، توبه کند؟ آیا کسی هست که قبل از فرا رسیدن روز دشوار قیامت، اعمال نیکی انجام دهد؟  آگاه باشید! هم اکنون در روزگار آرزوهایید، که مرگ را در پی دارد، پس هرکس در ایّام آرزوها،پیش از فرا رسیدن مرگ، عمل نیکو انجام دهد، بهره مند خواهد شد، و مرگ او را زیانی نمی رساند، و آن کس که در روزهای آرزوها، پیش از فرا رسیدن مرگ کوتاهی کند، زیانکار و مرگ او زیانبار است؛ همانگونه که به هنگام ترس و ناراحتی برای خدا عمل می کنید، در روزگار خوشی وکامیابی نیز عمل کنید. آگاه باشید!هرگز چیزی مانند بهشت ندیدم که خوستاران آن در خواب غفلت باشند، و نه چیزی مانند اتش جهنّم، که فراریان آن چنین در خواب فرو رفته باشند!. آگاه باشید! آن کس را که در حق منفعت نرساند، باطل به او زیان خواهد رساند، و آن کس که هدایت راهنمای او نباشد، گمراهی او را به هلاکت خواهد افکند. آگاه باشید! به کوچ کردن فرمان یافتید و برای جمع آوری توشه ی آخرت راهنایی شدید.همانا، وحشتناک ترین چیزی که بر شما می ترسم، هواپرستی، وآرزوهای دراز است. پس، از این دنیا توشه برگیرید تا فردا خود را با آن حفظ نمایید.

منبع:نهج البلاغه، خطبه 28

روش برخورد با دنیا

26- حضرت امام علی (علیه السّلام) فرمودند : ای مردم باید دنیای حرام در چشمانتان از پَرِ کاه خشکیده⁽¹⁾ و تُفاله های قیچی شده ی دام داران، بی ارزش تر باشد، از پیشینیان خود پند گیرید، پیش از آن که آیندگان از شما پند گیرند، این دنیای فاسد ِ نکوهش شده را رها کنید، زیرا مشتاقان شیفته تر از شما را رها کرد.

منبع: نهج البلاغه، خطبه 32

پرهیز از آرزوهای طولانی و هواپرستی

27- حضرت امام علی (علیه السّلام) فرمودند : ای مردم! همانا برای شما از دو چیز می ترسم: هواپرستی و آرزوهای طولانی. امّا پیروی از خواهش نفس، انسان را از حق باز می دارد، و آرزوهای طولانی، آخرت را از یاد می برد. آگاه باشید! دنیا به سرعت پشت کرده و از آن جز باقیمانده ی اندکی از ظرف آبی که آن را خالی کرده باشند، نمانده است. بهوش باشید که آخرت به سوی ما می آید، دنیا و آخرت، هریک فرزندانی دارند. بکوشید از فرزندان آخرت باشید، نه دنیا، زیرا در روز قیامت، هر فرزندی به پدر ومادر خویش باز می گردد. امروز هنگام عمل نه حسابرسی، و فردا روز حسابرسی است نه عمل.

منبع: نهج البلاغه، خطبه 42

روش برخورد با دنیا

28- حضرت امام علی (علیه السّلام) فرمودند : دنیا خانه ی آرزوهایی است که زود نابود می شود، و کوچ کردن از وطن حتمی است. دنیا شیرین و خوش منظر است که به سرعت به سوی خواهانش می رود، و بیننده را می فریبد، سعی کنید با بهترین زاد و توشه از آن کوچ کنید و بیش از کفاف خود از آن نخواهید و بیشتر از آنچه نیاز دارید طلب نکنید.

منبع: نهج البلاغه، خطبه 45

تعریف دنیا

29- حضرت امام علی (علیه السّلام) فرمودند : آگاه باشید، گویا دنیا پایان یافته، و وداع خویش را اعلام داشته است، خوبی هایش ناشناخته مانده به سرعت پُشت کرده می گذرد، ساکنان خود را به سوی نابودی شدن می کشاند، و همسایگانش را به سوی مرگ می راند. آنچه از دنیا شیرین بود تلخ شده، و آنچه صاف و زلال بود تیرگی پذیرفت، و بیش از ته مانده ی ظرف آب ریخته شده از آن باقی نمانده است، یا جرعه ای آب که با آن عطش تشنگان دنیا فرو نخواهد نشست.ای بندگان خدا! از سرایی کوچ کنید که سرانجام ِ آن نابودی است، مبادا! آرزوها بر شما چیره گردد، مپندارید که عمر طولانی خواهید داشت!

منبع: نهج البلاغه، خطبه 52

30- حضرت امام علی (علیه السّلام) فرموده اند: آنکس که با روزگار دشمنی کند، هلاک خواهد شد.

منبع تحف العقول ، ص85

روش برخورد با دنیا

31- آگاه باشید! دنیا خانه ای است که کسی در ان ایمنی ندارد جز آنکه به جمع اوری توشه ی آخرت پردازد و از کارهای دنیایی کسی نجات نمی یابد.

مردم به وسیله دنیا ازمایش می شوند، پس هر چیزی از دنیا را برای دنیا به دست آورند از کفشان بیرون می رود، و بر آن محاسبه خواهند شد، و آنچه را در دنیا بای آخرت تهیّه کردند به آن خواهند رسید، و با آن خواهند ماند، دنیا در نظر خردمندان چونان سایه ای است که هنوز گسترش نیافته، کوتاه می گردد، و هنوز فزونی نیافته کاهش می یابد.

منبع: نهج البلاغه، خطبه 63

نکوهش دنیا و بیان زهد در دنیا

32- حضرت امام صادق (علیه السّلام) فرمودند: هر که نسبت به دنیا زاهد و بی رغبت باشد، خدا حکمت را در دلش بر جا دارد و زبانش را بدان گویا کند و او را به عیب های دنیا بینا سازد و درد و درمان آن را به او بفهماند و از دنیا درستش بیرون برد و به بهشت دار السلامش در آورد.

منبع :  اصول کافی جلد 4، ص 385

33- حضرت امام صادق (علیه السّلام) فرمودند: پیغمبر غمنده بیرون رفت، یک فرشته ای که همراهش کلیدهای گنجینه های زمین بود نزد او آمد و به اوگفت: ای محمد، اینها کلیدهای گنجهای زمین است، پروردگارت می فرمایند: باز کن و هر چه خواهی از آنها برگیر بی آنکه چیزی از آنها کم شود در نزد من، رسول خدا (صلّی الله علیه و آله و سلّم) فرمودند: دنیا خانه ی کسی است که خانه ندارد و کسی که خرد ندارد برای آن جمع می کند، آن فرشته گفت: بدانکه تو را به راستی مبعوث کرده، به راستی من این سخن را از فرشته ای شنیدم که در آسمان چهارم بود هنگامی که این کلیدها را به من دادند.

منبع : اصول کافی جلد 4، ص 389

34- عبدالله بن قاسم گوید حضرت امام صادق (علیه السّلام) فرمودند: رسول خدا (صلّی الله علیه و آله و سلّم) به یک بزغاله گوش بریده که مرده بود و بر زباله دانی افتاده بود گذر کرد و به اصحاب خود فرمودند: این به چه می ارزد؟ درپاسخ گفتند: اگر زنده بود شاید یک درهم هم نمی ارزید، پیغمبر (صلّی الله علیه و آله و سلّم) فرمودند: بدانکه جانم به دست او است، هر آینه دنیا نزد خدا از این بزغاله ی مرده نزد صاحبش بی ارزش تر است.

منبع : اصول کافی جلد 4، ص 389

35- رسول خدا(صلّی الله علیه و آله و سلّم) فرمودند: به راستی در دنیاداری زیان به آخرت است و در طلب آخرت زیان به دنیا، شما به دنیای خود زیان بزنید که بهتر است از زیان رساندن به آخرت.

منبع : اصول کافی جلد 4، ص 393

36- ابی حذا گوید: به حضرت امام باقر (علیه السّلام) گفتم: برای من بازگو آنچه را بدان سود گیرم. فرموند: ای ابا عبیده بسیار یاد مرگ کن، زیرا آدمی نباشد که یاد مرگ کند جز آنکه در دنیا بی رغبت شود.

منبع : اصول کافی جلد 4، ص 395

37- حضرت رسول خدا (صلّی الله علیه و آله و سلّم) فرمودند: مرا با دنیا چه کار؟ همانا مثل من با او چون مثل شتر سواری است که درختی بر فراز او باشد در روز گرمی و زیر آن استراحت نیم روز را بگذراند و سپس برود و آن را به جا گذارد.

منبع : اصول کافی جلد 4، ص 401

38- حضرت امام صادق (علیه السّلام) فرمودند: نمونه ی دنیا چونان آب شور دریا است، هر آنچه تشنه از آن بنوشد به تشنگی او بیفزاید تا او را بکشد.

منبع : اصول کافی جلد 4، ص 409

39- وشاء گوید : از حضرت امام رضا (علیه السّلام) شنیدم، می فرمودند: عیسی بن مریم (علیه السّلام) به حواریین خود گفت: ای زاده های اسرائیل ، افسوس مخورید بدانچه از دنیا از دست دادید، چنانچه دنیاداران بدانچه از دینشان از دست دهند افسوس نخورند هر گاه به دنیای خود برسند.

منبع : اصول کافی جلد 4، ص 409

40- حضرت امام صادق (علیه السّلام) فرموده اند: کسی که به دنیا دل بسته و در بند علاقه اش اسیر است همواره گرفتار سه حالت روحی است: غصه و اندوهی که هرگز از صفحه ی دلش زدوده نمی شود، آرزویی که هرگز برآورده نمی گردد، و امیدی که هرگز به آن دست نمی یابد.

منبع: کافی،ج2،ص320

www.ez12.persianblog.ir

با تشکر از انتخاب شما

به تازگی داستانی تخیلی و کوتاه با نام  "مشاور" به نوشته‌ی رابین اسلون برای همکاری با موسسه‌ی Data & Society  در سایت مادربرد منتشر شده است.  این داستان به عنوان بخشی از پروژه‌ی  Intelligence & Autonomy، راه هایی را بررسی می‌کند که هوش مصنوعی بوسیله‌ی آن می‌تواند بر رفتار انسان مسلط شود. در این پروژه یافته های دنیای واقعی در زمینه‌ی هوش مصنوعی با داستان های علمی تخیلی به تصویر کشیده می‌شوند.

مطلبی که می‌خوانید در واقع قسمت دوم  همین داستان است که موضوعات مطرح شده در  داستان مشاور را به شکلی غیر روایی بیان می‌کند. در هر دوی این مقاله ها مسئله‌ی هوش مصنوعی از منظر جدیدی دیده می‌شوند و مباحثی بیان می‌شوند که به ناچار و در آینده ای نه چندان دور با آن روبرو خواهیم شد.

داستان مشاور از این قرار است که یک مرد ۹۵ ساله در برابر  ماشین هوشمندی قرار می‌گیرد که خودش قبلا ساخته است. جالب اینجاست که جنگ میان این دو نفر یک جنگ روانی است و ماشین سعی دارد تا مرد را متقاعد کند که وقت مرگش رسیده و بهتر است به زندگی خود پایان دهد.

این ماشین مشاور سوال می‌پرسد و سکوت های معنی داری دارد. حتی به گونه ای طراحی شده است که از مذهب نیز برای قانع کردن بیمارش استفاده می‌کند. بیمار نیز سعی می‌کند تا تحت تاثیر گفته های او قرار نگرفته و برای زنده ماندن خود تلاش کند.   

در این داستان علاوه براینکه یک دید کلی از آینده‌ی جهان هوشمند به کاربران داده می‌شود، سعی شده تا سیستم های مورد استفاده برای طراحی ماشین های هوشمند نیز تحلیل شود. نکته اینجاست که طراحان باید در انتخاب متدهایی که روی ماشین های هوشمند پیاده سازی می‌کنند، دقت بیشتری داشته و استفاده از برخی روش ها را کنار بگذارند.

این پرسش که چه چیزی باعث می‌شود که سیستمی خاصیت قانع کنندگی بخود بگیرد، پیچیده تر از آنست که به نظر می‌رسد. اما جالب است بدانید که در بسیاری از مواقع شما ممکن است توسط شخصی یا مکانیزمی قانع شوید بدون اینکه حتی بدانید که چه اتفاقی روی داده است.

امکان صحبت کردن در یک ماشین باعث می‌شود تا قدرت بیشتری در متقاعد کردن داشته باشد و رفتار خود را بر اساس واکنش کاربران تغییر دهد. ترفند ELIZA  در علم کامپیوتر به معنای روشی است که در آن هوش مصنوعی تلاش می‌کند تا با یک سیستم ساده‌ی پرسش و پاسخ و از روی واکنش عاطفی کاربران، اطلاعات شخصی آن ها را استنتاج کند.

در نظر گرفتن جنسیت بخصوص جنس مونث برای ماشین های هوشمند تاثیر مثبتی روی قدرت قانع کنندگی آن ها دارد. طبق نتایج یک پروژه‌ی تحقیقاتی در دانشگاه MIT، کاربران در برابر رباتی با ظاهر یک انسان  کمتر احساس خطر می‌کنند.

البته اخیرا مفاهیمی بیان شده است که نشان می‌دهد سیستم های هوشمند قدرتمند آن هایی هستند که بدون نیاز به یک بدن فیزیکی و یا شخصیت انسانی می‌توانند طرف مقابل خود را متقاعد کنند. برای مثال خبرخوان فیسبوک سیستم هوشمندی است که مطالب منتشر شده را براساس علایق کاربران به آن ها نمایش می‌دهد. الگوریتم به کار رفته در این نمایش می‌تواند روی نظر ما در انتخابات، احساسات‌ و دیدگاه های مخالف‌مان در هر زمینه ای تاثیر زیادی داشته باشد.

این قدرت متقاعد کردن در ماشین ها می‌تواند بسیار خطرناک‌تر از سیستم ماشینی و بدون احساسی باشد که برای آینده‌ی جهان هوشمند تصور می‌شود. به هر حال هوش مصنوعی تنها به معنی ربات‌هایی با ظاهر انسان و یا یک ماشین الکترونیکی نیست. همین اتومبیل‌های بدون راننده‌ی امروزی و یا موتور های جست وجو نمونه‌ای ملموس از هوش مصنوعی هستند.

سیستم‌های هوشمند طراحانی دارند که درباره‌ی نحوه‌ی رفتار آن ها تصمیم گیری می‌کنند. در داستان مشاور، جنگ اصلی میان مرد بیمار و سیستمی است که خودش قبلا آن را طراحی کرده است. در این مدل طراحی، سازندگان سعی داشته‌اند تا رفتار کاربرانی را که از سیستم‌شان استفاده می‌کنند، تحت تاثیر قرار دهند.  

به هر حال هوش مصنوعی از این دیدگاه سه چالش اساسی را پیش روی ما می‌گذارد. اول اینکه سیستم های هوشمند می‌توانند به گفته‌ی کاربران گوش داده و با نتیجه گرفتن از آن رفتارهای جدیدی را شکل دهند. شاید در گذشته کمتر روی این موضوع تاکید می‌شد اما ماشین های توانمند امروزی باید چنین قدرتی داشته باشند.

دوم اینکه ماشین های هوشمند ماندگار هستند. کاربران می‌توانند برای مدت طولانی با یک عامل هوشمند مانند سیری زندگی کنند. در گذشته دسترسی به سیستم ماشین ها و بهبود ان مشکل بود اما اکنون و مخصوصا با آمدن معماری ابری عمر مفید سیستم های هوشمند نسبت به گذشته افزایش قابل توجهی داشته است.

چالش سوم نیز این است که نمی‌توان به این راحتی ها و با پرسش و پاسخ هدف یک ماشین هوشمند را دریافت. تجربه‌ی تعامل با یک ماشین هوشمند بسیار دشوار است. مثلا یک کاربر به سختی می‌تواند تشخیص دهد که رفتار ماشین در طول زمان تغییر کرده است یا خیر.

این سه ویژگی تنها دلیل نگرانی ما برای آینده‌ی هوش مصنوعی نیست. تصمیمی که طراحان در نحوه‌ی پیاده سازی هوش مصنوعی می‌گیرند، بسیار مهم است. درست مانند اینکه به ماشین اجازه دهیم تا چه چیزی را بخرد و روی چه چیزی کلیک کند.

آنچه که در داستان مشاور کاملا مشهود است داشتن میزان قدرتی است که به ماشین هوشمند اجازه می‌دهد تا فعالیت متقاعد کننده ای را انجام دهد که برای انسان نامناسب است. در واقع مدل مشاوره ای این داستان مغایر با ضوابط پزشکی است. برای همین است که گفته می‌شود در آینده ای نزدیک تدوین ابزارهای مختلف برای دادن توانایی متقاعد کردن به ماشین های هوشمند، به یکی از دغدغه های اصلی طراحان تبدیل خواهد شد. البته باید در نظر بگیریم که این توانایی برای کمک به استقلال و همچنین باهوش تر شدن ماشین ها به آن ها داده می‌شود.

اینکه این اختیار وسیع‌تر و قدرتمند تر از توانایی انسان باشد یا نه، تصمیم مهمی است که باید در اینباره گرفته شود. بهترین تصمیم در این خصوص این است که برای ماشین های هوشمند اختیار محدودتری را در نظر بگیریم تا انسان ها استقلال بیشتری در تصمیم گیری های خود داشته باشند.

کاروان ها در سکوت و دزدها در قال و قیل

سال ها این دشت نشنیده است آوای رحیل

کوچ کردن قصه شد، مردانه ماندن یک خیال

کودکان افسانه می بافند از مردان ایل

بوی رخوت راه های دشت را پر کرده است

روز باران گله را خوابانده چوپان در مسیل

غرق در افسون فرعونی کسی راهی نشد

پا به پای اعتقاد هیچ موسایی به نیل

بر زمین تا چشم می بیند مترسک کاشتند

در فراسوی زمان مُردند مردان اصیل

انتهای هیچ راهی منزلی پیدا نبود

جاده ها آزرده از یک امتداد بی دلیل

(Learn JavaScript Higher-order Functions, aka Callback Functions)

In JavaScript, functions are first-class objects; that is, functions are of the type Object and they can be used in a first-class manner like any other object (String, Array, Number, etc.) since they are in fact objects themselves. They can be “stored in variables, passed as arguments to functions, created within functions, and returned from functions”¹.

Because functions are first-class objects, we can pass a function as an argument in another function and later execute that passed-in function or even return it to be executed later. This is the essence of using callback functions in JavaScript. In the rest of this article we will learn everything about JavaScript callback functions. Callback functions are probably the most widely used functional programming technique in JavaScript, and you can find them in just about every piece of JavaScript and jQuery code, yet they remain mysterious to many JavaScript developers. The mystery will be no more, by the time you finish reading this article.

Callback functions are derived from a programming paradigm known as functional programming. At a fundamental level, functional programming specifies the use of functions as arguments. Functional programming was—and still is, though to a much lesser extent today—seen as an esoteric technique of specially trained, master programmers.

Fortunately, the techniques of functional programming have been elucidated so that mere mortals like you and me can understand and use them with ease. One of the chief techniques in functional programming happens to be callback functions. As you will read shortly, implementing callback functions is as easy as passing regular variables as arguments. This technique is so simple that I wonder why it is mostly covered in advanced JavaScript topics.

What is a Callback or Higher-order Function?

A callback function, also known as a higher-order function, is a function that is passed to another function (let’s call this other function “otherFunction”) as a parameter, and the callback function is called (or executed) inside the otherFunction. A callback function is essentially a pattern (an established solution to a common problem), and therefore, the use of a callback function is also known as a callback pattern.

Consider this common use of a callback function in jQuery:

//Note that the item in the click method's parameter is a function, not a variable.
//The item is a callback function
$("#btn_1").click(function() {
  alert("Btn 1 Clicked");
});

As you see in the preceding example, we pass a function as a parameter to the click method. And the click method will call (or execute) the callback function we passed to it. This example illustrates a typical use of callback functions in JavaScript, and one widely used in jQuery.

Ruminate on this other classic example of callback functions in basic JavaScript:

var friends = ["Mike", "Stacy", "Andy", "Rick"];

friends.forEach(function (eachName, index){
console.log(index + 1 + ". " + eachName); // 1. Mike, 2. Stacy, 3. Andy, 4. Rick
});

Again, note the way we pass an anonymous function (a function without a name) to the forEach method as a parameter.

So far we have passed anonymous functions as a parameter to other functions or methods. Lets now understand how callbacks work before we look at more concrete examples and start making our own callback functions.

How Callback Functions Work?

We can pass functions around like variables and return them in functions and use them in other functions. When we pass a callback function as an argument to another function, we are only passing the function definition. We are not executing the function in the parameter. In other words, we aren’t passing the function with the trailing pair of executing parenthesis () like we do when we are executing a function.

And since the containing function has the callback function in its parameter as a function definition, it can execute the callback anytime.

Note that the callback function is not executed immediately. It is “called back” (hence the name) at some specified point inside the containing function’s body. So, even though the first jQuery example looked like this:

//The anonymous function is not being executed there in the parameter. 
//The item is a callback function
$("#btn_1").click(function() {
  alert("Btn 1 Clicked");
});

the anonymous function will be called later inside the function body. Even without a name, it can still be accessed later via the arguments object by the containing function.

Callback Functions Are Closures
When we pass a callback function as an argument to another function, the callback is executed at some point inside the containing function’s body just as if the callback were defined in the containing function. This means the callback is a closure. Read my post, Understand JavaScript Closures With Ease for more on closures. As we know, closures have access to the containing function’s scope, so the callback function can access the containing functions’ variables, and even the variables from the global scope.

Basic Principles when Implementing Callback Functions

While uncomplicated, callback functions have a few noteworthy principles we should be familiar with when implementing them.

Use Named OR Anonymous Functions as Callbacks
In the earlier jQuery and forEach examples, we used anonymous functions that were defined in the parameter of the containing function. That is one of the common patterns for using callback functions. Another popular pattern is to declare a named function and pass the name of that function to the parameter. Consider this:


// global variable
var allUserData = [];

// generic logStuff function that prints to console
function logStuff (userData) {
    if ( typeof userData === "string")
    {
        console.log(userData);
    }
    else if ( typeof userData === "object")
    {
        for (var item in userData) {
            console.log(item + ": " + userData[item]);
        }

    }

}

// A function that takes two parameters, the last one a callback function
function getInput (options, callback) {
    allUserData.push (options);
    callback (options);

}

// When we call the getInput function, we pass logStuff as a parameter.
// So logStuff will be the function that will called back (or executed) inside the getInput function
getInput ({name:"Rich", speciality:"JavaScript"}, logStuff);
//  name: Rich
// speciality: JavaScript

Pass Parameters to Callback Functions
Since the callback function is just a normal function when it is executed, we can pass parameters to it. We can pass any of the containing function’s properties (or global properties) as parameters to the callback function. In the preceding example, we pass options as a parameter to the callback function. Let’s pass a global variable and a local variable:

//Global variable
var generalLastName = "Clinton";

function getInput (options, callback) {
    allUserData.push (options);
// Pass the global variable generalLastName to the callback function
    callback (generalLastName, options);
}

Make Sure Callback is a Function Before Executing It
It is always wise to check that the callback function passed in the parameter is indeed a function before calling it. Also, it is good practice to make the callback function optional.

Let’s refactor the getInput function from the previous example to ensure these checks are in place.

function getInput(options, callback) {
    allUserData.push(options);

    // Make sure the callback is a function
    if (typeof callback === "function") {
    // Call it, since we have confirmed it is callable
        callback(options);
    }
}

Without the check in place, if the getInput function is called either without the callback function as a parameter or in place of a function a non-function is passed, our code will result in a runtime error.

Problem When Using Methods With The this Object as Callbacks
When the callback function is a method that uses the this object, we have to modify how we execute the callback function to preserve the this object context. Or else the this object will either point to the global window object (in the browser), if callback was passed to a global function. Or it will point to the object of the containing method.
Let’s explore this in code:


// Define an object with some properties and a method
// We will later pass the method as a callback function to another function
var clientData = {
    id: 094545,
    fullName: "Not Set",
    // setUserName is a method on the clientData object
    setUserName: function (firstName, lastName)  {
        // this refers to the fullName property in this object
      this.fullName = firstName + " " + lastName;
    }
}

function getUserInput(firstName, lastName, callback)  {
    // Do other stuff to validate firstName/lastName here

    // Now save the names
    callback (firstName, lastName);
}

In the following code example, when clientData.setUserName is executed, this.fullName will not set the fullName property on the clientData object. Instead, it will set fullName on the window object, since getUserInput is a global function. This happens because the this object in the global function points to the window object.

getUserInput ("Barack", "Obama", clientData.setUserName);

console.log (clientData.fullName);// Not Set

// The fullName property was initialized on the window object
console.log (window.fullName); // Barack Obama

Use the Call or Apply Function To Preserve this
We can fix the preceding problem by using the Call or Apply function (we will discuss these in a full blog post later). For now, know that every function in JavaScript has two methods: Call and Apply. And these methods are used to set the this object inside the function and to pass arguments to the functions.

Call takes the value to be used as the this object inside the function as the first parameter, and the remaining arguments to be passed to the function are passed individually (separated by commas of course). The Apply function’s first parameter is also the value to be used as the this object inside the function, while the last parameter is an array of values (or the arguments object) to pass to the function.

This sounds complex, but lets see how easy it is to use Apply or Call. To fix the problem in the previous example, we will use the Apply function thus:

//Note that we have added an extra parameter for the callback object, called "callbackObj"
function getUserInput(firstName, lastName, callback, callbackObj)  {
    // Do other stuff to validate name here

    // The use of the Apply function below will set the this object to be callbackObj
    callback.apply (callbackObj, [firstName, lastName]);
}

With the Apply function setting the this object correctly, we can now correctly execute the callback and have it set the fullName property correctly on the clientData object:

// We pass the clientData.setUserName method and the clientData object as parameters. The clientData object will be used by the Apply function to set the this object

getUserInput ("Barack", "Obama", clientData.setUserName, clientData);

// the fullName property on the clientData was correctly set
console.log (clientData.fullName); // Barack Obama

We would have also used the Call function, but in this case we used the Apply function.

Multiple Callback Functions Allowed
We can pass more than one callback functions into the parameter of a function, just like we can pass more than one variable. Here is a classic example with jQuery’s AJAX function:

function successCallback() {
    // Do stuff before send
}

function successCallback() {
    // Do stuff if success message received
}

function completeCallback() {
    // Do stuff upon completion
}

function errorCallback() {
    // Do stuff if error received
}

$.ajax({
    url:"http://fiddle.jshell.net/favicon.png",
    success:successCallback,
    complete:completeCallback,
    error:errorCallback

});

“Callback Hell” Problem And Solution

In asynchronous code execution, which is simply execution of code in any order, sometimes it is common to have numerous levels of callback functions to the extent that you have code that looks like the following. The messy code below is called callback hell because of the difficulty of following the code due to the many callbacks. I took this example from the node-mongodb-native, a MongoDB driver for Node.js. [2]. The example code below is just for demonstration:

var p_client = new Db('integration_tests_20', new Server("127.0.0.1", 27017, {}), {'pk':CustomPKFactory});
p_client.open(function(err, p_client) {
    p_client.dropDatabase(function(err, done) {
        p_client.createCollection('test_custom_key', function(err, collection) {
            collection.insert({'a':1}, function(err, docs) {
                collection.find({'_id':new ObjectID("aaaaaaaaaaaa")}, function(err, cursor) {
                    cursor.toArray(function(err, items) {
                        test.assertEquals(1, items.length);

                        // Let's close the db
                        p_client.close();
                    });
                });
            });
        });
    });
});

You are not likely to encounter this problem often in your code, but when you do—and you will from time to time—here are two solutions to this problem. [3]

1. Name your functions and declare them and pass just the name of the function as the callback, instead of defining an anonymous function in the parameter of the main function.
2. Modularity: Separate your code into modules, so you can export a section of code that does a particular job. Then you can import that module into your larger application.

Make Your Own Callback Functions

Now that you completely (I think you do; if not it is a quick reread :)) understand everything about JavaScript callback functions and you have seen that using callback functions are rather simple yet powerful, you should look at your own code for opportunities to use callback functions, for they will allow you to:

• Do not repeat code (DRY—Do Not Repeat Yourself)
• Implement better abstraction where you can have more generic functions that are versatile (can handle all sorts of functionalities)
• Have better maintainability
• Have more readable code
• Have more specialized functions.

It is rather easy to make your own callback functions. In the following example, I could have created one function to do all the work: retrieve the user data, create a generic poem with the data, and greet the user. This would have been a messy function with much if/else statements and, even still, it would have been very limited and incapable of carrying out other functionalities the application might need with the user data.

Instead, I left the implementation for added functionality up to the callback functions, so that the main function that retrieves the user data can perform virtually any task with the user data by simply passing the user’s full name and gender as parameters to the callback function and then executing the callback function.

In short, the getUserInput function is versatile: it can execute all sorts of callback functions with myriad of functionalities.

// First, setup the generic poem creator function; it will be the callback function in the getUserInput function below.
function genericPoemMaker(name, gender) {
    console.log(name + " is finer than fine wine.");
    console.log("Altruistic and noble for the modern time.");
    console.log("Always admirably adorned with the latest style.");
    console.log("A " + gender + " of unfortunate tragedies who still manages a perpetual smile");
}

//The callback, which is the last item in the parameter, will be our genericPoemMaker function we defined above.
function getUserInput(firstName, lastName, gender, callback) {
    var fullName = firstName + " " + lastName;

    // Make sure the callback is a function
    if (typeof callback === "function") {
    // Execute the callback function and pass the parameters to it
    callback(fullName, gender);
    }
}

Call the getUserInput function and pass the genericPoemMaker function as a callback:

getUserInput("Michael", "Fassbender", "Man", genericPoemMaker);
// Output
/* Michael Fassbender is finer than fine wine.
Altruistic and noble for the modern time.
Always admirably adorned with the latest style.
A Man of unfortunate tragedies who still manages a perpetual smile.
*/

Because the getUserInput function is only handling the retrieving of data, we can pass any callback to it. For example, we can pass a greetUser function like this:

function greetUser(customerName, sex)  {
   var salutation  = sex && sex === "Man" ? "Mr." : "Ms.";
  console.log("Hello, " + salutation + " " + customerName);
}

// Pass the greetUser function as a callback to getUserInput
getUserInput("Bill", "Gates", "Man", greetUser);

// And this is the output
Hello, Mr. Bill Gates

We called the same getUserInput function as we did before, but this time it performed a completely different task.

As you see, callback functions afford much versatility. And even though the preceding example is relatively simple, imagine how much work you can save yourself and how well abstracted your code will be if you start using callback functions. Go for it. Do it in the monings; do it in the evenings; do it when you are down; do it when you are k

Note the following ways we frequently use callback functions in JavaScript, especially in modern web application development, in libraries, and in frameworks:


• For asynchronous execution (such as reading files, and making HTTP requests)
• In Event Listeners/Handlers
• In setTimeout and setInterval methods
• For Generalization: code conciseness

Final Words

JavaScript callback functions are wonderful and powerful to use and they provide great benefits to your web applications and code. You should use them when the need arises; look for ways to refactor your code for Abstraction, Maintainability, and Readability with callback functions.

See you next time, and remember to keep coming back because JavaScriptIsSexy.com has much to teach you and you have much to learn.

Notes

1. http://c2.com/cgi/wiki?FirstClass
2. https://github.com/mongodb/node-mongodb-native
3. http://callbackhell.com/
4. JavaScript Patterns by Stoyan Stefanov (Sep 28, 2010)

DecorateThis

DecorateThis (GitHub: mako-taco/DecorateThis, License: Apache 2.0, npm: decorate-this) by Jake Scott is the first library to my knowledge that takes advantage of ES7 decorators. Decorators allow you to annotate classes and properties.

An example of a decorator is @readonly:

class Person {  
  @readonly
  name() { return `${this.first} ${this.last}` }
}

This is far less complex than the older Object.defineProperty syntax:

Object.defineProperty(Person.prototype, 'name', {  
  value: specifiedFunction,
  enumerable: false,
  configurable: true,
  writable: true
});

The DecorateThis module provides some very handy decorators for argument type checking, including:

• Memoization: @memoized
• Type validation: primitive types @param(Number), and a class T is checked with @param(T)
• Duck type checks: @param({ hello: String, info: { age: Number, color: String } });

If these checks fail type errors are thrown, which means you'll need exception handlers for places where these checks should be caught and handled gracefully.

jsRequest

Bruno Panuto and Danilo Valente have been working on a JavaScript file loader called jsRequest (GitHub: danilo-valente/jsRequest, License: MIT) since back in 2013. It handles asynchronous loading, and the syntax supports loading multiple files with a chained API:

jsRequest  
  .load('myScript.js')
  .load('http://code.jquery.com/jquery-1.10.2.js')
  .load('file:///C:/myFile.js');

It supports extra options that allow success and failure callbacks to be supplied, and it also has a progress callback. If you need to order requests, then you can use the wait method.

jsRequest tracks the request history, so if you need to check what files have been loaded you can inspect the jsRequest.history object.

ODataAngularResources

I recently wrote about OData Server, and Raphael Atallah sent in ODataAngularResources (GitHub: devnixs/ODataAngularResources, License: MIT), a fork of Angular's $resource that allows making OData queries using a fluent API.

Once you've added the dependency, you can do cool stuff like this:

var User = $odataresource('/user/:userId', { userId:'@id' });  
var myUsers = User.odata()  
  .filter('Name', 'John')
  .query();

You can also use top, orderBy, and skip, and request single elements. The readme has full examples including details on how to create more complex queries with predicates.

More libraries are starting to blend ideas from functional programming, streams, and reactive programming. Yassine Elouafi sent in ADT Streams (License: MIT, npm: adtstream), a library that offers a stream API using promises and algebraic data types. It has methods for wrapping other streams, like Stream.fromReadable for use with Node's Readable streams, Stream.fromEmitter for objects that extend EventEmitter, and Stream.fromDomEvent for working with DOM events in the browser.

There are utility methods, like Stream.seq for yielding elements from a sequence over time. The blog post, Promises + FP = Beautiful Streams explains each of the library's methods with examples first in Haskell and then in JavaScript. It also has some background on streams and reactive programming:

The basic idea is that you can represent different asynchronous data like events or http responses by an unifying concept called observable collections. Then you can manipulate those collections by standard array operations like map, filter, reduce, forEach ...etc.

By using Yassine's library, you can compose streams with different sources: you can mix events and readable streams with the same API.

The author also wrote From callback to (Future -> Functor -> Monad), which argues why callbacks are not composable and alternative solutions:

With composition, you never hit a wall, because you must always ask yourself "What is the return value of this function?", or put another way "What is the meaning of this thing?"

I don't mind using callbacks in my code. In fact, callbacks are great for things such as representing side effects or event notification, but once your start using them to manage your control flow, you're trapped, why? because they do not compose.

Both of these posts will be of interest to you if you're a JavaScript programmer without much functional or reactive programming experience.