From a Beginner to a Disaster

IMPORTANT:
Some of the content here is a personal summary/abbreviation of contents on the Offical Go Documentation. Feel free to refer to the official site if you think some of the sections written here are not clear.

Installing Go

Please follow the Offical Guide on Installing Go.

Packages

(additional reference: https://www.callicoder.com/golang-packages/#:~:text=Go%20Package,following%20syntax%20%2D%20package)

Every Go program is made up of packages, and every Go source file belongs to a package. To declare a source file to be part of a package, we use the following syntax -

1

package <packagename>

The above package declaration must be the first line of code in your Go source file. All the functions, types, and variables defined in your Go source file become part of the declared package.

You can choose to export a member defined in your package to outside packages, or keep them private to the same package. Other packages can import and reuse the functions or types that are exported from your package.

Let’s see an example

Almost all the code that we will see in this tutorial series include the following line -

1

import "fmt"

fmt is a core library package that contains functionalities related to formatting and printing output or reading input from various I/O sources. It exports functions like Println(), Printf(), Scanf() etc, for other packages to reuse.

Note:

• By convention, the package name is the same as the last element of the import path. For instance, the "math/rand" package comprises files that begin with the statement package rand.

The main package and main() function

Go programs start running in the main package. It is a special package that is used with programs that are meant to be executable. The main() function is a special function that is the entry point of an executable program.

By convention, Executable programs (the ones with the main package) are called Commands. Others are called simply Packages.

IMPORTANT:
Some of the content here is a personal summary/abbreviation of contents on the Offical Spring Framework Documentation. Feel free to refer to the official site if you think some of the sections written here are not clear.

This is a Guide, since it is mostly conceptual and does not include much actual coding (except for examples illustrating those concepts). For more practical uses/examples, please refer to the Spring Boot Manual or the Spring Cloud Manual.

Spring Intro

The term “Spring” means different things in different contexts. It can be used to refer to the Spring Framework project itself, which is where it all started. Over time, other Spring projects have been built on top of the Spring Framework. Most often, when people say “Spring”, they mean the entire family of projects. This reference documentation focuses on the foundation: the Spring Framework itself.

When you learn about a framework, it’s important to know not only what it does but what principles it follows. Here are the guiding principles of the Spring Framework:

• Provide choice at every level. Spring lets you defer design decisions as late as possible. For example, you can switch persistence providers through configuration without changing your code.
• Accommodate diverse perspectives. Spring embraces flexibility and is not opinionated about how things should be done. It supports a wide range of application needs with different perspectives.
• Maintain strong backward compatibility. Spring’s evolution has been carefully managed to force few breaking changes between versions. Spring supports a carefully chosen range of JDK versions and third-party libraries to facilitate maintenance of applications and libraries that depend on Spring.
• Care about API design. The Spring team puts a lot of thought and time into making APIs that are intuitive and that hold up across many versions and many years.
• Set high standards for code quality. The Spring Framework puts a strong emphasis on meaningful, current, and accurate javadoc. It is one of very few projects that can claim clean code structure with no circular dependencies between packages.

IoC - Inversion of Control

IoC is also known as dependency injection (DI). It is a process whereby objects define their dependencies (that is, the other objects they work with) only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse (hence the name, Inversion of Control) of the bean itself controlling the instantiation or location of its dependencies by using direct construction of classes or a mechanism such as the Service Locator pattern.

In Spring, the objects that form the backbone of your application and that are managed by the Spring IoC container are called beans. A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. Otherwise, a bean is simply one of many objects in your application. Beans, and the dependencies among them, are reflected in the configuration metadata used by a container.

The main tasks performed by IoC container are:

• to instantiate the application class
• to configure the object
• to assemble the dependencies between the objects

And there are two types of IoC containers. They are:

• BeanFactory (org.springframework.beans)
• ApplicationContext (org.springframework.context)

In short, the BeanFactory provides the configuration framework and basic functionality, and the ApplicationContext adds more enterprise-specific functionality. The ApplicationContext is a complete superset of the BeanFactory and is used exclusively in this chapter in descriptions of Spring’s IoC container. For more information on using the BeanFactory instead of the ApplicationContext, see The BeanFactory.

Java Beans vs Spring Beans vs POJOs

(additional reference: http://www.shaunabram.com/beans-vs-pojos/)

• JavaBeans are classes that encapsulate many objects into a single object (the bean). It is a java class that should follow following conventions:

  • Must implement Serializable.

  • It should have a public no-arg constructor.

  • All properties in java bean must be private with public getters() and public setter() methods.

    1 2 3 4 5 6 7 8 9 10

    public class TestBean { private String name; public void setName(String name){ this.name = name; } public String getName(){ return name; } }

  setter methods:

  • It should be public in nature.
  • The return-type should be void.
  • The setter method should be prefixed with set.
  • It should take some argument i.e. it should not be no-arg method.

  getter methods

  • It should be public in nature.
  • The return-type should not be void i.e. according to our requirement we have to give return-type.
  • The getter method should be prefixed with get.
  • It should not take any argument.

  Boolean properties getter method

  • name can be prefixed with either “get” or “is”. But recommended to use “is”.
  • returns a boolean

IMPORTANT:
Some of the content here is a personal summary/abbreviation of contents on the Offical Redis Guide. Feel free to refer to the official site if you think some of the sections written here are not clear.

Redis Intro

Redis is an in-memory remote database that offers high performance, replication, and a unique data model to produce a platform for solving problems. By supporting five different types of data structures (Strings, Lists, Sets, Hashes, and Sorted sets), Redis accommodates a wide variety of problems that can be naturally mapped into what Redis offers.

To be specific, Redis is a very fast non-relational database that stores a mapping of keys to five different types of values. Redis supports in-memory persistent storage on disk, replication to scale read performance, and client-side sharding1 to scale write performance.

• non-relational
  • In Redis, there are no tables, and there’s no database-defined or -enforced way of relating data in Redis with other data in Redis. Generally speaking, many Redis users will choose to store data in Redis only when the performance or functionality of Redis is necessary, using other relational or non-relational data storage for data where slower performance is acceptable, or where data is too large to fit in memory economically.

Data Structures in Redis

In the following sections, we will use the redis cli to pratice using redis commands and data structures.

Strings in Redis - Basics

The operations available to STRINGs start with what’s available in other key-value stores. We can GETvalues, SET values, and DEL values. After you have installed and tested Redis, within redis-cli you can try to SET, GET, and DEL values in Redis. The basic meanings are shown below in the table: