Month: November 2017

Descriptive Statistics

Observational Studies, Surveys, Controlled Experiments, , Blind, Double Blind, Placebo, Random assignment of sample

Population (mu, population average)

Sample (x bar, sample average), Random Sample

Statistic (Average sleep time of sample of students, characteristic of a sample)

Parameter (Average sleep time of population)

Variable (Age, Height of a population): Whether someone is alive or dead, Scores on an intelligence test, number of friends on facebook

Lurking (Extraneous) Variables:

Constructs: Measured

Operational Definition: a way of turning constructs into variables we can measure, a way of describing variables in terms of the way we measure it

Sampling Error

Research Studies

Screen Shot 2017-11-13 at 9.17.16 AM.png

Screen Shot 2017-11-13 at 9.19.24 AM.png

Screen Shot 2017-11-13 at 9.21.44 AM.png

Screen Shot 2017-11-13 at 9.25.34 AM.png

Screen Shot 2017-11-13 at 9.28.58 AM.png


Spring and Spring Boot Useful Details

  1. Does Spring framework create a proxy for every bean?

Spring does not create a proxy for every bean. For example, classes marked with the @Service, @Repository, @Controller annotations do not have a proxy by default.

Spring will create a Dynamic Proxy for beans implementing an interface if some behavior needs to be added. For example, if a class is marked with the @Transactional annotation, Spring creates a dynamic proxy using the JDK reflection API. JDK Proxies only work with beans that implement an interface. To enforce JDK proxy use

<aop:config proxy-target-class=”false”>

For classes that do not implement an interface, spring can still create a proxy using cglib or any other library that is packaged with it for creating the proxies.

Spring repackages cglib into a different package structure to allow applications that need to use a different version of cglib easy. Otherwise there would be conflicts.

When there are multiple behaviors added to a class, for example logging and transaction, several proxies may be created. In such cases, we can advise spring the order in which the behavior needs to be applied using the @Order annotation.

2.  What is the need for Spring Boot?

Spring Framework aims to simplify Java Applications Development. Spring Boot eases the development of Spring applications.

Spring Boot Framework has the following components:

  1. Spring Boot Starter
  2. Spring Boot AutoConfigurator
  3. Spring Boot Actuator
  4. Spring Boot CLI
  5. Spring Boot Initilizr

Excellent article covering spring boot components and some internals of SpringBoot.  – shows a sample Web Application developed in Spring Boot. There is no configuration like adding a web.xml, default handlermapping beans etc that need to be added. All these are automatically configured by SpringBoot.

To use Declarative transaction management with Spring we would have to use

<tx:annotation-driven/>; Add a transactionManager, dataSource bean to our spring context file. All these would not be required with Spring Boot.

3.  What is the use of DispatcherServlet and ContextLoaderListener?

DispatcherServlet is the front controller in the Spring MVC application and it loads the spring bean configuration file and initialize all the beans that are configured. If annotations are enabled, it also scans the packages and configure any bean annotated with @Component@Controller@Repository or @Service annotations.

ContextLoaderListener is the listener to start up and shut down Spring’s root WebApplicationContext. It’s important functions are to tie up the lifecycle of ApplicationContext to the lifecycle of the ServletContext and to automate the creation of ApplicationContext. We can use it to define shared beans that can be used across different spring contexts.

4.  Can we have multiple Spring configuration files?

For Spring MVC applications, we can define multiple spring context configuration files through contextConfigLocation. This location string can consist of multiple locations separated by any number of commas and spaces. For example;


We can also define multiple root level spring configurations and load it through context-param. For example;

	<param-value>/WEB-INF/spring/root-context.xml /WEB-INF/spring/root-security.xml</param-value>

Another option is to use import element in the context configuration file to import other configurations, for example:

<beans:import resource="spring-jdbc.xml"/>


5.  Name some of the design patterns used in Spring Framework?

Spring Framework is using a lot of design patterns, some of the common ones are:

  1. Singleton Pattern: Creating beans with default scope.
  2. Factory Pattern: Bean Factory classes
  3. Prototype Pattern: Bean scopes
  4. Adapter Pattern: Spring Web and Spring MVC
  5. Proxy Pattern: Spring Aspect Oriented Programming support
  6. Template Method Pattern: JdbcTemplate, HibernateTemplate etc
  7. Front Controller: Spring MVC DispatcherServlet
  8. Data Access Object: Spring DAO support
  9. Dependency Injection and Aspect Oriented Programming

 6.  What are some of the best practices for Spring Framework?

  1. Avoid version numbers in schema reference, to make sure we have the latest configs.
  2. Divide spring bean configurations based on their concerns such as spring-jdbc.xml, spring-security.xml.
  3. For spring beans that are used in multiple contexts in Spring MVC, create them in the root context and initialize with listener.
  4. Configure bean dependencies as much as possible, try to avoid autowiring as much as possible.
  5. For application level properties, best approach is to create a property file and read it in the spring bean configuration file.
  6. For smaller applications, annotations are useful but for larger applications annotations can become a pain. If we have all the configuration in xml files, maintaining it will be easier.
  7. Use correct annotations for components for understanding the purpose easily. For services use @Service and for DAO beans use @Repository.
  8. Spring framework has a lot of modules, use what you need. Remove all the extra dependencies that gets usually added when you create projects through Spring Tool Suite templates.
  9. If you are using Aspects, make sure to keep the join pint as narrow as possible to avoid advice on unwanted methods. Consider custom annotations that are easier to use and avoid any issues.
  10. Use dependency injection when there is actual benefit, just for the sake of loose-coupling don’t use it because it’s harder to maintain.

7.  Multiple ApplicationContexts and Root Contexts

Root Context

The root-context in a Spring application is the ApplicationContext that is loaded by the ContextLoaderListener. This context should have globally available resources like services, repositories, infrastructure beans (DataSourceEntityManagerFactorys etc.)

The ContextLoaderListener registers this context in the ServletContext under the name org.springframework.web.context.WebApplicationContext.ROOT.

If you load an ApplicationContext yourself and register it with the name above in the ServletContext that will then qualify as the root-context.

Child Context

The child-context in a Spring application is the ApplicationContext that is loaded by a DispatcherServlet (or for instance a MessageDispatcherServlet in a Spring-WS application). This context should only contain beans relevant to that context, for Spring MVC that would be ViewResolvers, HandlerMappings etc.

The servlet registers this context in the ServletContext under the name org.springframework.web.servlet.FrameworkServlet.CONTEXT.<servlet-name>.

Root <-Child Relation

Only child contexts have access to the parent context, because you could have multiple child contexts. For instance in an Spring MVC combined with Spring WS application. The parent-context is detect by the childs by finding it in the ServletContext with the well known name.

If the root context would have access to the child which one would it use to wire beans? Next to that if that would be the case you would also get surprising results when AOP is involved. AOP defined in the child context would suddenly influence beans configured in the root context.

8.   Spring XD

With the creation of the Spring for Apache Hadoop project, we made it easier to get started developing Hadoop applications by providing a rich configuration model and a consistent programming model across Hadoop ecosystem projects such as Hive and Pig. As Spring users would expect, one can:

    1. Configure and run MapReduce jobs as container managed objects.
    2. Use template helper classes for HDFS, HBase, Pig and Hive to remove boilerplate code from your applications.

Spring for Apache Hadoop provides a strong foundation for building Hadoop applications. Spring XD builds upon these foundational assets and further simplifies the process of creating real-world big data solutions. Specifically, Spring XD addresses common big data use-cases such as:

  1. High throughput distributed data ingestion into HDFS from a variety of input sources.
  2. Real-time analytics at ingestion time, e.g. gathering metrics and counting values.
  3. Hadoop workflow management via batch jobs that combine interactions with standard enterprise systems (e.g. RDBMS) as well as Hadoop operations (e.g. MapReduce, HDFS, Pig, Hive or Cascading).
  4. High throughput data export, e.g. from HDFS to a RDBMS or NoSQL database.

9.  Spring Batch

A lightweight, comprehensive batch framework designed to enable the development of robust batch applications vital for the daily operations of enterprise systems.

Spring Batch provides reusable functions that are essential in processing large volumes of records, including logging/tracing, transaction management, job processing statistics, job restart, skip, and resource management. It also provides more advanced technical services and features that will enable extremely high-volume and high performance batch jobs through optimization and partitioning techniques. Simple as well as complex, high-volume batch jobs can leverage the framework in a highly scalable manner to process significant volumes of information.


  • Transaction management
  • Chunk based processing
  • Declarative I/O
  • Start/Stop/Restart
  • Retry/Skip
  • Web based administration interface (Spring Batch Admin)

10.   Spring Integration

Using the Spring Framework encourages developers to code using interfaces and use dependency injection (DI) to provide a Plain Old Java Object (POJO) with the dependencies it needs to perform its tasks. Spring Integration takes this concept one step further, where POJOs are wired together using a messaging paradigm and individual components may not be aware of other components in the application. Such an application is built by assembling fine-grained reusable components to form a higher level of functionality. With careful design, these flows can be modularized and also reused at an even higher level.

Enterprise Integration Patterns

In addition to wiring together fine-grained components, Spring Integration provides a wide selection of channel adapters and gateways to communicate with external systems. Channel Adapters are used for one-way integration (send or receive); gateways are used for request/reply scenarios (inbound or outbound). For a full list of adapters and gateways, refer to the reference documentation.

The Spring Cloud Stream project builds on Spring Integration, where Spring Integration is used as an engine for message-driven microservices.


  • Implementation of most of the Enterprise Integration Patterns
  • Endpoint
  • Channel (Point-to-point and Publish/Subscribe)
  • Aggregator
  • Filter
  • Transformer
  • Control Bus
  • Integration with External Systems
  • Twitter
  • WebServices (SOAP and ReST)
  • JMS
  • RabbitMQ
  • Email
  • The framework has extensive JMX support
  • Exposing framework components as MBeans
  • Adapters to obtain attributes from MBeans, invoke operations, send/receive notifications