Effect of Setting setTimeout to 0 and Explanation of JavaScript's Single Threaded, Non Blocking I/O, Async Event Driven Model

If you have two functions:

var f1 = function () {    
   setTimeout(function(){
      console.log("f1", "First function call...");
   }, 0);
};

var f2 = function () {
    console.log("f2", "Second call...");
};

and then you call them:

f1();
f2();

Checking your console, this is what you see:

If you were expecting to see "f1 First function call..." first, then you are not alone. This is what I initially expected based on my assumption that having a setTimeout set to 0 milliseconds, well mean, execute right away. Apparently this is not how things work.

This post is about how this unexpected behaviour led me into having a refresher of some of the core concepts regarding how JavaScript executes.

Understanding Entity Relationship Mapping, Part 2: Annotating Entity Relationships

In Understanding Entity Relationship Mapping, Part 1: The basic concepts I glazed over some of the basic concepts that would be encountered when dealing with establishing relationships between Entities. This post would take a look at how to use Annotations to specify these relationships.

The relationships that would be annotated are the four types that you have in relational data model:

1. One-To-One annotated with @OneToOne
2. Many-To-One annotated with @ManyToOne
3. One-To-Many annotated with @OneToMany
4. Many-To-Many annotated with @ManyToMany

If concepts like Cardinality, Direction of Relationship, Cascades, Owning side and Inverse side of Entity relationship is new to you, then it is would be good to first read Understanding Entity Relationship Mapping, Part 1: The basic concepts

The relationship would be classified into two: Single Valued Mappings and Collection Valued Mappings. It is worth stating that the examples were written with Hibernate's implementation of JPA in mind, but would work with any other standard implementation of JPA 2, as no Hibernate specific annotation is included.

So let us begin.

Understanding Entity Relationship Mapping, Part 1: The basic concepts

It is possible to create a working functionality of a system using tools/technologies that is not fully understood, as long as some minimal knowledge is present: what things are, where to find them, and how to wire them together in other to get them to work. And thank heavens, with the help of search engines, you can easily scour the web for solutions to anomalies that pops up, due to the lack of complete grasp of the tool being used. But without a more in-depth knowledge, or at least a grasp of the basic fundamental concepts, it would become difficult to accomplish more complex or customized tasks, troubleshoot issues and general extend beyond the basic functionality.

This was how I was treating mapping entity relationships in the ORM domain, via Hibernate's implementation of JPA, for a time now. I had the basic knowledge of relational database modelling, how relationships are constructed using primary keys and foreign keys in SQL, how data can be fetched from tables that are related using joins: basic knowledge that has its roots solely in the relational way of looking at databases. So I was able to annotate up entities and set up relationships. Get stuff persisted and maybe updated. But I kept running into minor errors now and then, configuration issues, minor oversights etc.

One of the areas these annoyances kept popping up was in how to describe relationships between entities. After I have had enough of head banging against the wall, I decided to just take a step back to understand, at least, a little bit more, the tool I am using and what I was dealing with here.

This blog post is the outcome of that stepping back. It has two parts to it. This post, which describes some basic terminologies that you would come across while working with most JPA implementations and the second: Understanding Entity Relationship Mapping, Part 2: Annotating Entity Relationships, which shows how entity relationships are annotated.

So here we go:

How To Use .call(), .apply() and .bind() In Javascript

Back in March I wrote a post "Understanding Constructor Functions in Javascript and This keyword" in which, while explaining the concept of this in Javascript, I stated that it is impossible to tell what the this keyword references by just looking at the function definition. You only get to decide or know what the this keyword refers to, by the way the function is called. Call the function one way, and have this refer to one object, call it another way and you can have it refer to a totally different object. Showing that in Javascript, this is a context-indicator.

I mentioned that normal calling of a function (i.e. have a function fx, call it via fx()) and calling with the new keyword i.e. (new fx()) are some of the various ways to call a Javascript function and have the this keyword switch context.

There are 3 other ways a Javascript function can be called with the ability to determine what this keyword references. call, apply and bind. To be technically specific: Function.prototype.call, Function.prototype.apply, and Function.prototype.bind.

Javascript is not Java. Deal with it

There are different paradigms when it comes to programming languages. With each paradigm, you have different and unique methods and concepts that are used in the task of computation and getting the computer to do what you want. Sometimes these concepts share similarities; sometimes they go about their task in totally different ways. The merit of a paradigm is thus judged against the backdrop of the problem it is being used to solve and whether it is the best fit.

It would then be totally silly and dense to put a language down solely on the fact that it incorporates a different paradigm when compared to a language you are familiar with. Most of the bashing I see targeted at Javascript is largely due to this: coming from a different programming paradigm and getting miffed when different ways of doing things are encountered in the Javascript land.

At the risk of being wrong and committing fallacy of hasty generalization, I would say Java developers are most guilty of this (maybe it has to do with the misleading "Java" in Javascript? :p)

I say this, because from personal experience, (which I know is limited) I do not get the same close mindedness from the Python, Ruby and C# devs that I know.(This explains the title of the post I guess :p)

Maybe it is that difficult to come to terms that Javascript is a prototype based object oriented language and not a class based language?

Consequences of this close mindedness towards Javascript, thus lead to hacks and practices that try to bend and mould Javascript into something which it is not. I most of the time find this to be quite uneducated.

Coming from a Javascript-first background, before Java, I guess made it quite hard for me to have this kind of narrow mindedness and priggish attitude? I guess this helps to easily appreciate the unique ways of doing things in both languages. I like to think that this makes a better developer, as it is quite interesting to see how different ideas are implemented across languages and borrow from them in situation, when it is germane.

So when (if) I want to learn Haskell, I won’t go about complaining over how it has so many concepts; tricky and odd concepts and how it does things different when compared to say Javascript. And I wont try to write Javascript in Haskell.

And by the way, Javascript is not the only language that has its good parts. Every language does, Java, C++ inclusive :)

Fixing org.springframework.http.converter.HttpMessageNotWritableException Error

A couple of days back, I ran into an interesting error while retrieving persisted entities as JSON  in SpringMVC:

[Request processing failed; nested exception is org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Infinite recursion (StackOverflowError)...

I had to do some poking around and reading up on documentation to figure out how to fix it.

As it turned out, the fix wasn't that complex and the culprit was Jackson: the Java-JSON processor being used to transform the retrieved Java entity to a JSON representation.

The error occurs when you try to retrieve an entity that has a bi-directional @OneToMany relationship with another entity.

Enum in Java.

Let us assume you have the need for some constants in your application; say the three primary colors: Red, Green, Blue. You could create a class specifically for holding the constants thus:

class PrimaryColorsStatic {
        public static final String RED = "red";
        public static final String GREEN = "green";
        public static final String BLUE = "blue";
}

and any of these can be used: PrimaryColorsStatic.RED or PrimaryColorsStatic.GREEN or PrimaryColorsStatic.BLUE

This would work, but it is very limited. Let say you want to hold, apart from the name, the hex code and rgb code of the color as part of the constant? How would this be done with the mechanism above? Whatever way you find to implement this would feel forced as static variables of classes were not designed to help fulfil such use cases.

Enum in Java provides a more robust mechanism for dealing with constant values in your application.

Enum can be formally defined as a special data type that enables for a variable to be a set of predefined constants.

The basic syntax is simple. The primary color example can be represented as an Enum with the following code:

public enum PrimaryColorsEnum {
     RED, GREEN, BLUE
}

[this means that the file would be saved as PrimaryColorsEnum.java]

and an example of accessing it would be:

public main void() {
    PrimaryColorsEnum RedHolder = PrimaryColorsEnum.RED;
    System.out.println(RedHolder);
}

This would print red to the console as a string.

Just knowing the above syntax and when to use it could get you by with Enum, but you have hardly scratched the surface with just that.

To fully appreciate Enums, let us take a step back and see if we can grok the concept in a more detailed level.