How to face an Interview

At some point in our life to get  a job we will most likely to be faced an interview. Apart from knowing background information about the job, the way you face it, your communication, your appearance will also make a difference.

1. Conduct Research on the Employer, Hiring Manager, and Job Opportunity

2. Review Common Interview Questions and Prepare Your Responses

3. Dress for Success

4. Arrive on Time, Relaxed and Prepared for the Interview

5. Make Good First Impressions

6. Be Authentic, Upbeat, Focused, Confident, Candid, and Concise

7. Remember the Importance of Body Language

8. Ask Insightful Questions.

9. Sell Yourself and then Close the Deal

10. Thank Interviewer(s) in Person, by Email, or Postal Mail.

Hamcrest Matchers in JUnit tests

Normal assertions in JUnit would look like this: 

Assert.assertEquals(expectedValue, actualValue); for example Assert.assertEquals(3, bean.getValue());

With hamcrest matchers, we can make the tests much more expressive and with recent versions of JUnit, core hamcrest matchers are bundled with JUnit and so there is no need to download and add hamcrest to our classpath explicitly.

JUnit has this new static method in org.junit.Assert called assertThat which has signature like this:

assertThat(actual, Matcher);

Using this, we can make the tests very expressive. First add some of the static imports:

import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsNot.not;
import static org.hamcrest.core.IsEqual.equalTo;
import static org.hamcrest.core.IsNull.nullValue;
import static org.junit.Assert.assertThat;

Then, assertions can look like this:

      assertThat(bean.getValue(), is(equalTo(3)));
      assertThat(bean.toString(), is("XYZ"));
      assertThat(bean.getNewValue(), is(nullValue());
      assertThat(bean.getType(), is(not(nullValue()));

This shows how readable these tests are when compared to the regular assertions. Also, we can see that matchers can be nested. In the above block, is and not, is and equalTo, is and nullValue() are chained to make it more readable.

There are more matchers available in org.hamcrest.core package inside junit jar. In Eclipse, you can open up the junit jar under referenced libraries and navigate to this particular folder in package explorer to see other available matchers.

Basics of AngularJS

Architecture

Models are scope objects in Angular. In traditional MVC, the model encapsulates information to be displayed by a View. Scoping is really just another way of saying, "This is a container for this view."

Notice that the Controller implements the scoped logic. It does the heavy lifting while handing off the results to the Model, which then relays it to the View. You can think of the Model as an interface, whereas the Controller is the implementation of this interface.

Angular breaks down the implementation further to be handled by Services. A service in Angular is implementation logic that would otherwise be in a controller. The purpose of moving this logic out of the controller is to avoid "fat controllers."

There are several architectural concepts used by Angular that you should be aware of. These concepts are described in the following sections.

Two Way Binding

Two way binding (TWB) is a concept that means Angular will update your Model automatically, or as necessary, when users input data into your forms. This tight-coupling between input values and their corresponding variable representation in the Model makes handling data much easier—without having to watch for user-driven events.

TWB has been around a long time in OO language frameworks such as Java Struts and .NET MVC. The concept is new In JavaScript, however, and Angular makes this introduction into the JavaScript framework world only to be followed by a host of other JavaScript frameworks that have come out after Angular that do the same things.

Dirty Checking

Dirty checking (DC) variable data conceptually means that you do not have to use getter and setter methods (as you do with OO languages such as C# or Java) to update your View data. Using getters and setters in those languages are meant to ensure data encapsulation, an OO concept that means that your instance variables should not be directly accessible.

Although JavaScript is not an OO language, DC variable data would make sense. But in my opinion, it somewhat compromises the MVC architectural model because this model is an OO-based model, and not enforcing data encapsulation weakens this architectural principle.

Dependency Injection

Dependency injection (DI) is a bit difficult to grasp conceptually. It is another whole article (even book) topic of its own, but remember that it refers to injecting types at run-time.

Because JavaScript is not a compiler language, it is more natural for it to embrace DI because objects can change identity while the script is active. DI can be thought of as dynamic Factory objects that return a certain type based on the context of a type request.

If you have studied OO languages, you should make this connection easily. For example, suppose that we have a Factory named Animal and want to return animal types of a cat, dog, or rabbit. It can be done using a Factory pattern.

DI is much the same, but it is backward. Using a Factory, we would have to call the correct constructor by passing in a variable to the Factory base class that will tell us what constructor to return. This is not a bad thing, but requires the base class to know about all the lower-level classes that derive from the base class.

With DI, the base class does not have to know what classes are derived from it. How can this be achieved? To put it simply, an Interface is used to bridge the derived classes to the base class. Now, the behavior is reversed, so we have dependency inversion.

With DI in effect, we can just pass in the type of animal for which we want a constructor, and the base class will return the correct one—but by using a single implementation that implements the interface that the derived classes are also using.

Directives

Directives are special tags in Angular that define a certain binding to an element section of a page. For example, if we want to put all our logic output handled by a controller into a <div> section, we can use the directive ng-controller.

In effect, this means that only this section has controller-related output logic. See the Hello World example below for further clarification.